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
Upon encountering a duplicate entry, frontend crashes with a non-informative message: "asyncpg.exceptions.CardinalityViolationError: ON CONFLICT DO UPDATE command cannot affect row a second time"
For "normal" mode it's already pretty time-consuming to debug, but for diff mode it's even much more difficult.
Would it be possible to, every time a CardinalityViolationError is encountered, frontend automatically prints a log statement CardinalityViolationError encountered. Duplicate entry - item: {...} - class: {...} - subclass: {...} - elements: [{...}]
(in case a duplicate error is the cause of course)
Possibly with extra output like diff_mode: {yes|no} and Encountered: {number of times this duplicate exists}, but these are only 'nice to have'.
I suspect it's most efficient to do this on frontend, as there it could be in a try/catch block and only run in case of an actual failure. Naturally it should still make sure the analyser reports a fail, otherwise it won't be detected.
The text was updated successfully, but these errors were encountered:
Upon encountering a duplicate entry, frontend crashes with a non-informative message:
"asyncpg.exceptions.CardinalityViolationError: ON CONFLICT DO UPDATE command cannot affect row a second time"
For "normal" mode it's already pretty time-consuming to debug, but for diff mode it's even much more difficult.
Would it be possible to, every time a CardinalityViolationError is encountered, frontend automatically prints a log statement
CardinalityViolationError encountered. Duplicate entry - item: {...} - class: {...} - subclass: {...} - elements: [{...}]
(in case a duplicate error is the cause of course)
Possibly with extra output like
diff_mode: {yes|no}
andEncountered: {number of times this duplicate exists}
, but these are only 'nice to have'.I suspect it's most efficient to do this on frontend, as there it could be in a try/catch block and only run in case of an actual failure. Naturally it should still make sure the analyser reports a fail, otherwise it won't be detected.
The text was updated successfully, but these errors were encountered: