-
Notifications
You must be signed in to change notification settings - Fork 61
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
[ENG-6654] fixfix: correct misunderstanding, handle conflicts #836
[ENG-6654] fixfix: correct misunderstanding, handle conflicts #836
Conversation
8f54393
to
99f3eb2
Compare
- messages can _only_ be ack'd thru the channel they were received by -- trying to recover a channel to ack thru does nothing - handle easily-detectable delete_by_query conflicts in a followup celery task (so the indexer doesn't fall over on it)
99f3eb2
to
adc9b83
Compare
try avoiding connection errors when calling `message.ack()` -- do a bit more book-keeping to know when a bulk elastic action is the last for its index-card, so it can ack immediately then instead of waiting 'til the whole chunk has completed
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.
One Q, one minor thing to mitigate TODOs, but generally looks good.
Pass complete
'card_pks': messages_chunk.target_ids_chunk, | ||
'timestamp': messages_chunk.timestamp, | ||
}, | ||
countdown=3, # TODO: config? |
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.
Minor: Should probably be configurable, yes.
Something like
settings.ELASTICSEARCH['COUNTDOWN_DELAY'] = int(os.environ.get('ELASTICSEARCH_COUNTDOWN_DELAY', 3))
would probably be reasonable
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.
went with ELASTICSEARCH_POST_INDEX_DELAY
ensure_ack
,ack_callback
) -- messages can only be ack'd thru the channel they were received by, so trying to recover a channel to ack thru does nothingdaemon
user to access elastic8message.ack()
-- do a bit more book-keeping to know when a bulk elastic action is the last for its index-card, so it can ack immediately then instead of waiting 'til the whole chunk has completed