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
Describe the bug
When I try to submit via UI a file that already exists in the malware archive, and it is old enough to have already been removed from the normal submissions, the UI fails with a timeout visible in the browser's networking tab. On the backend site, the ui container is freaking out with ConflictError exceptions and endless retries. In addition, it looks like interrupted submissions (e.g. because of restarting the container) aren't immediately removed from the quota - but I suspect they will be removed after some timeout.
To Reproduce
Steps to reproduce the behavior:
Have an archived submission that is after its TTL, and has already been removed from the normal submission index.
Go to the Submit page, open web developer tools to observe network traffic.
Try to upload the same file as in the submission from (1).
Wait until you see get an error in the UI or the traffic inspector.
Go to the logs of ui container.
Observe endless retries with the errors like: {"@timestamp": "2024-03-28 23:28:30,167", "event": { "module": "assemblyline", "dataset": "assemblyline.datastore" }, "host": { "ip": "172.16.0.6", "hostname": "7209ae405eaa" }, "log": { "level": "INFO", "logger": "assemblyline.datastore" }, "process": { "pid": "7" }, "message": "Retrying save or freshen due to version conflict: ConflictError(409, 'version_conflict_engine_exception', '[xxx]: version conflict, required seqNo [13307], primary term [35]. but no document was found')"}
Side note: due to the nature of gevent server workers, processing the request in ui container isn't interrupted even after being closed on the nginx side.
Expected behavior
I can upload a file even if it's already in the archive. The file is normally processed, and I eventually see additional information from the archive.
Screenshots
Environment (please complete the following information if pertinent):
Assemblyline Version: 4.5.0.7
Browser: Firefox
Additional context
I reproduced this with a few files, freshly expired (a day after TTL) as well as much older one (a few months after TTL). When I tried a file that is in the archive, but hasn't been expired yet, there was no problem.
The text was updated successfully, but these errors were encountered:
kam193
added
assess
We still haven't decided if this will be worked on or not
bug
Something isn't working
labels
Mar 28, 2024
Describe the bug
When I try to submit via UI a file that already exists in the malware archive, and it is old enough to have already been removed from the normal submissions, the UI fails with a timeout visible in the browser's networking tab. On the backend site, the
ui
container is freaking out withConflictError
exceptions and endless retries. In addition, it looks like interrupted submissions (e.g. because of restarting the container) aren't immediately removed from the quota - but I suspect they will be removed after some timeout.To Reproduce
Steps to reproduce the behavior:
ui
container.{"@timestamp": "2024-03-28 23:28:30,167", "event": { "module": "assemblyline", "dataset": "assemblyline.datastore" }, "host": { "ip": "172.16.0.6", "hostname": "7209ae405eaa" }, "log": { "level": "INFO", "logger": "assemblyline.datastore" }, "process": { "pid": "7" }, "message": "Retrying save or freshen due to version conflict: ConflictError(409, 'version_conflict_engine_exception', '[xxx]: version conflict, required seqNo [13307], primary term [35]. but no document was found')"}
ui
container isn't interrupted even after being closed on the nginx side.Expected behavior
I can upload a file even if it's already in the archive. The file is normally processed, and I eventually see additional information from the archive.
Screenshots
Environment (please complete the following information if pertinent):
Additional context
I reproduced this with a few files, freshly expired (a day after TTL) as well as much older one (a few months after TTL). When I tried a file that is in the archive, but hasn't been expired yet, there was no problem.
The text was updated successfully, but these errors were encountered: