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 rbt gets a Job from Roc, it uses the information to create a key, which is then used as the identifier for the job in the build graph. However unlikely it is, it's possible that we could get a collision there.
To guard against this, rbt could keep a mapping of key to job while constructing the build graph. Every time we got a new job, we'd insert into this mapping. If we already had an item in there, we'd verify that the new value was exactly equal to the existing one. If it wasn't, we'd raise an error and ask the caller to set some field designed to avoid hash collisions.
When rbt gets a
Job
from Roc, it uses the information to create a key, which is then used as the identifier for the job in the build graph. However unlikely it is, it's possible that we could get a collision there.To guard against this, rbt could keep a mapping of key to job while constructing the build graph. Every time we got a new job, we'd insert into this mapping. If we already had an item in there, we'd verify that the new value was exactly equal to the existing one. If it wasn't, we'd raise an error and ask the caller to set some field designed to avoid hash collisions.
Thanks, @bhansconnect, for the idea of how to mitigate this!
The text was updated successfully, but these errors were encountered: