Main & Chain Processes Fail After Successful Arkose Attempt - Major Bug Report

[martin@rootjazz]

https://rootjazz.com/twitterdub/updatetesting.html

[Rev]

ok I see it. The "denied by access control" response flags the account that it needs to perform a login to validate itself. This is what used to have to be done. But now it means an arkose captcha, which wasn't, on successful completion wiping the flag on the account.

The next update will fix this. I shall let you know when it is ready.



Regards,
Martin

ok I see it. The "denied by access control" response flags the account that it needs to perform a login to validate itself. This is what used to have to be done. But now it means an arkose captcha, which wasn't, on successful completion wiping the flag on the account.

The next update will fix this. I shall let you know when it is ready.



Regards,
Martin

It still doesn't work. I just tried to reproduce this issue with the latest version (3.563) of update-testing and the issue is still prevalent. It seems there are some new/additional error messages in logs of the failed process, so here they are: logs_24638

[Rev]

It still doesn't work. I just tried to reproduce this issue with the latest version (3.563) of update-testing and the issue is still prevalent. It seems there are some new/additional error messages in logs of the failed process, so here they are: logs_24638

Is there any updates on this matter?

[958]

Yes Verification failure log prompts to use a proxy. I used a proxy. Points were also deducted. However, the verification task was not completed. Log: 87944

[Rev]

Yes Verification failure log prompts to use a proxy. I used a proxy. Points were also deducted. However, the verification task was not completed. Log: 87944

I don't know what is your use-case is or how you encounter this issue specifically but, this exact thing happens to me when I manually add proxies to accounts that had no available or in-use proxies assigned to them previously and most importantly, the actual cause of this (in my case) is not checking the "Validate on save" option-box before saving my changes. Even though the software shows you that it saved the given proxy information for the account (after the initial edit/change of your account information), without the "Validate on save" option-box checked, the software doesn't really apply the specific changes to the account till these changes are validated somehow.

I'm not implying that this is an actual "bug" or an issue to be dealt with. It's most likely that, this is how the overall changes to the accounts' information is being processed and validated by the software. As mentioned, I'm just sharing what happens in case of what I am trying to achieve. I can't tell with the absolute certainty that this is what you are experiencing from what you have shared.

[martin@rootjazz]

It still doesn't work. I just tried to reproduce this issue with the latest version (3.563) of update-testing and the issue is still prevalent. It seems there are some new/additional error messages in logs of the failed process, so here they are: logs_24638

Is there any updates on this matter?

Sorry, I will take a look - slipped my mind

[martin@rootjazz]

ok looks like twitter updated the usermedia endpoint, which broke the random job function.

The next update will fix this. I shall let you know when it is ready.

Or just try it again probably you will get a different random job, or disable random action




Regards,
Martin

[martin@rootjazz]

https://rootjazz.com/twitterdub/updatetesting.html

try this please, tbh I am not sure it will resolve completely but should get us a step further up the chain to the root issue



Regards,
Martin

[Rev]

ok looks like twitter updated the usermedia endpoint, which broke the random job function.

The next update will fix this. I shall let you know when it is ready.

Or just try it again probably you will get a different random job, or disable random action




Regards,
Martin

https://rootjazz.com/twitterdub/updatetesting.html

try this please, tbh I am not sure it will resolve completely but should get us a step further up the chain to the root issue



Regards,
Martin

The issue is ongoing for both "random action" included or not. Tried on the latest update-testing version (3.564) of the software.

With "random action": logs_65813
Without "random action": logs_47678

Also, I can't tell if this is intended but, even though accounts get automatically arkose-unlocked by the captcha-solver services, the software (database, etc.) still counts them as arkose-locked till a manual account-verification via "View Accounts" tab is commenced. I believe this behaviour is the culprit. It seems like the software deems accounts unreachable which are/were challenged by arkose until a manual check is applied. This behaviour still applies to those accounts that had been already automatically unlocked by the captcha-solver services.

[martin@rootjazz]

ok looks like twitter updated the usermedia endpoint, which broke the random job function.

The next update will fix this. I shall let you know when it is ready.

Or just try it again probably you will get a different random job, or disable random action




Regards,
Martin

https://rootjazz.com/twitterdub/updatetesting.html

try this please, tbh I am not sure it will resolve completely but should get us a step further up the chain to the root issue



Regards,
Martin

The issue is ongoing for both "random action" included or not. Tried on the latest update-testing version (3.564) of the software.

I think I misunderstood the issue you were reporting as the usermedia random issue is fixed and confirmed.

With "random action": logs_65813
Without "random action": logs_47678

let me have another look and see if I can see what you are referring to