You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you remove an alias from an object, the new list of aliases is passed to a field patch mutation, that reset entirely the list of aliases.
Doing so, each alias of the list is checked against the live database to see if it collides with an existing object.
It makes sense as we theoretically change the whole list, but in the case of a removal, this should not be necessary.
An object can have a very long list of aliases (happens in prod, ~200 aliases on a malware), so this step can in fact consume a lot of processing and queries.
NB: In one case, this lead to errors in production (an old database with somehow colliding aliases = check fails on removing any alias).
This is an edge-case that should not be possible as we have proper check in place now.
Environment
ALL
Reproducible Steps
Create many aliases for a malware.
Try to delete one of them
checkout the query payload: it's the whole list passed as a field patch.
Additional information
We could optimize this process by calling a field patch with object_path at the right index, and remove operation.
In that case, no check for duplicate necessary.
Incidentally, it would solve our edge-case as removing any alias will always be possible, and manually solving the existing alias duplicates would be ok.
The text was updated successfully, but these errors were encountered:
labo-flg
added
bug
use for describing something not working as expected
needs triage
use to identify issue needing triage from Filigran Product team
labels
May 20, 2024
Description
When you remove an alias from an object, the new list of aliases is passed to a field patch mutation, that reset entirely the list of aliases.
Doing so, each alias of the list is checked against the live database to see if it collides with an existing object.
It makes sense as we theoretically change the whole list, but in the case of a removal, this should not be necessary.
An object can have a very long list of aliases (happens in prod, ~200 aliases on a malware), so this step can in fact consume a lot of processing and queries.
NB: In one case, this lead to errors in production (an old database with somehow colliding aliases = check fails on removing any alias).
This is an edge-case that should not be possible as we have proper check in place now.
Environment
ALL
Reproducible Steps
Create many aliases for a malware.
Try to delete one of them
checkout the query payload: it's the whole list passed as a field patch.
Additional information
We could optimize this process by calling a field patch with
object_path
at the right index, andremove
operation.In that case, no check for duplicate necessary.
Incidentally, it would solve our edge-case as removing any alias will always be possible, and manually solving the existing alias duplicates would be ok.
The text was updated successfully, but these errors were encountered: