-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resend txn & Handle dropped txns #70 #72
base: develop
Are you sure you want to change the base?
Conversation
rubocop displays 1265 offenses from all over the project, so not sure what to do about it |
@bshevchenko Don't worry about the warnings. We are using |
Can you run |
@FrancisMurilloDigix done! Draft code for cron job is within the watching_transaction module (resend). Need your feedback on it. Job itself should be configured depending on the server environment, which I am not aware of. Btw, as far as I am concerned, @roynalnaruto is supposed to be the reviewer for this PR, no? |
@bshevchenko I am the main developer for the Rails application so I am also the reviewer. For the cron job, checkout |
@FrancisMurilloDigix all right, thank you! So shall I just put my code there under the "schedule.every '5m' do"? |
@bshevchenko 5m is fine. Was going to comment whether we can remove the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initial set of comments.
@FrancisMurilloDigix ran out of your comments. Please check new commits |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More comprehensive set of comments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still reviewing the tests.
The group_id
for rewatch
might be incorrect or misunderstood so watch out for that. Gonna try to stay open for tomorrow if you have more questions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost done.
So, as of now, I see 6 unresolved conversations that are related to:
On 1 I'll soon provide new commits, but for 2 I need more feedback |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For 2, you are right about the receipt and txhash so we have to take the extra txhash
field for watchTransaction
.
@FrancisMurilloDigix check out my latest commit please |
@FrancisMurilloDigix or even 3 latest commits. They include what was lacking. I hope that's all |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost there.
@FrancisMurilloDigix everything seems to be resolved to me |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty pleased with this.
Just some enhancements on the test and one forgotten test on the WatchedTransaction
@FrancisMurilloDigix check latests commits please |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done. When you're done addressing this last touch up.
- Do
rubocop -a
and commit the files again. - Do squash the commits
|
||
WatchingTransaction.resend_transactions | ||
|
||
assert_requested(get_failed_stub, times: 1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use size
instead of 1
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's supposed to be 1, because if API is unavailable then no more attempts will be made during current job
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it is called for each transaction so it is n
times instead of 1
. You should try setting it to n
and then n+1
to see the effect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, it breaks whole cycle. Tests are passing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You missed few new lines in watching_transaction.rb:
if ok_tx == :error
Rails.logger.info 'Failed to get transaction by hash. Killing job..'
break
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@FrancisMurilloDigix I'm not getting what you trying to say
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, got it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll anyway break on the next iteration
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if API would be still unavailable
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even if the next iteration fails and the reason is that the API is down or a network issue, then returning or breaking early is fine. Since error handling is not truly addressed, at least the consistency of behavior is the same when either request is down.
Yeah, so adding a break
or return
on a failed send_raw_transaction
is good enough for now.
All right, but I'm curious why you don't just use "Squash and merge" feature? |
2510186
to
0b61e36
Compare
@FrancisMurilloDigix done |
Thanks for your hard work. Will merge after some advice from @tymat Will add the remaining |
Description
Types of changes
Checklist:
rubocop
.schema, do update the documentation via
apipie
or the schema itself.bin/rake test
with highcode coverage(at least 90%).