-
Notifications
You must be signed in to change notification settings - Fork 5
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
Support queuing score by id #114
Conversation
makes it easier to test handling arbitrary data instead of making different QueueItem subclasses
@notbakaneko to confirm, is this ready to go? |
The |
Noticed some strange errors earlier; it should work properly now - I'll move the parts that organize the items to index/delete out later |
README.md
Outdated
### Deleting a score by `id` | ||
```json | ||
{ "Action": "delete", "ScoreId": 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.
What's the case for deleting? Wondering if we even need an action if the deletion case is always "doesn't exist in database or has preserve=0
.
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.
So a document can be deleted directly when testing for effects.
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.
So it will never be used in actual usages?
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's a convenience when testing
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.
I mean, considering it's going to be fetching from a mysql table at the end of the day (where you can set preserve:false
) it's probably fine to remove here to keep things simple then?
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.
Being able to just delete it makes it easier than needing to flip preserve
between true and false on he db first; with the command I can just do score delete 1
to remove and score index 1
to put it back; it also means not needing an entire infrastructure and complete dataset to always be present and be in sync when testing 👀
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.
I still don't get it. The indexer does lookups from the database. How do you test without data/infrastructure?
If this is really required, can we keep it on a dev branch, as I don't foresee it being useful in production?
var redis = new Redis(); | ||
var database = redis.Connection.GetDatabase(); | ||
var queueName = $"osu-queue:score-index-{AppSettings.Schema}"; | ||
|
||
database.ListLeftPush(queueName, value); |
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.
Any reason for doing it like this rather than using the existing queue method? I'd much prefer the latter.
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.
This makes it easier to push arbitrary structures into the queue for testing instead of it being serialized into a known type, or defining a new type and queue processor instance for every payload I want to check.
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.
But you can just new ScoreItem { id = ... }
no?
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.
Pushing directly to the key allows pushing things like { "ScoreId": 1, "not_a_real_field": "aa" }
and also intentionally omit properties that didn't exist in other versions, instead of it being serialized into to type of the current version, which isn't as useful when testing for payloads from external sources.
processor.PushToQueue(new ScoreItem())
is always going to push "{\"Action\":null,\"ScoreId\":null,\"Score\":null,\"TotalRetries\":0,\"Tags\":null}"
to the queue; a different client isn't necessarily going to be sending all the fields.
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.
I guess it's fine to leave this, since this command probably won't be used in production. Still a bit weird though. I can imagine this breaking if we change the queue name or system and forget to update this. shrug
@notbakaneko I've applied some changes and tested locally that things still seem to work. Of concern is 1e8f036 where I change the deletion operation to use |
@@ -86,23 +85,6 @@ private void addToBuffer(SoloScore score, ProcessableItemsBuffer buffer) | |||
buffer.Deletions.Add(score.id); | |||
} | |||
|
|||
private BulkResponse dispatch(BulkDescriptor bulkDescriptor) |
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.
this isn't supposed to be unused; apparently I managed to test it and somehow not push the change using 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.
Did you want to add the usage back for this then?
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.
I was going to update the calls to it but there was an issue I came across when checking ES8 support, except I can't seem to replicate it now 🤔
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.
The new logic means that if ES goes away, the queue processor will never exit. I don't think this should be the case? Queue processor itself already has fail and retry logic, so unless this is intended to handle actual intermittent errors during normal operation, I'd either leave the handling to that mechanism, or make it retry for a max of 1-5 seconds to ensure things don't get stuck.
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.
Retrying queue items with minimal delay can easily deplete all the retries while a server restarts or network recovers; a better way may be to be able to just re-queue an item without it being marked as failed?
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.
Maybe a setting on QueueProcessor
that ensures failed items are never dropped, for cases that matters.
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.
Will merge as-is for now and we can revisit when this becomes an issue. Tracking at ppy/osu-queue-processor#16.
The original call was |
Yeah I saw that, but seems |
@@ -86,23 +85,6 @@ private void addToBuffer(SoloScore score, ProcessableItemsBuffer buffer) | |||
buffer.Deletions.Add(score.id); | |||
} | |||
|
|||
private BulkResponse dispatch(BulkDescriptor bulkDescriptor) |
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.
The new logic means that if ES goes away, the queue processor will never exit. I don't think this should be the case? Queue processor itself already has fail and retry logic, so unless this is intended to handle actual intermittent errors during normal operation, I'd either leave the handling to that mechanism, or make it retry for a max of 1-5 seconds to ensure things don't get stuck.
Adds support for queuing solo_score for indexing by
id
.The indexer will do the necessary lookups and index or delete the document as necessary; scores with missing user or beatmap will be deleted from the index.
The structure of
SoloScore
is specific to the indexer itself and probably not convenient for other clients to use, especially if the format changes.To queue for indexing, push to the queue:
ScoreId
in the queue item will have priority overScore
(score gets ignored)Added some utility commands:
To queue a score for indexing or deletion by
id
:Pushing the contents of
filename
to the queue as a single item - this is mainly so I can test with arbitrary json blobs instead of the result ofJsonConvert.SerializeObject
:Also adds theconvert
flag to the schema but haven't added added the convert lookup yet.Also does the
convert
lookup (assuming score'sruleset_id
being different from beatmap'splaymode
)closes #112