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
Found during the investigation for #1710, where it is documented as explicitly out of scope.
Current Behavior
The eligibility rules for "ask WBIA whether it has this annotation" and "actually send this annotation to WBIA" disagree, so some annotations are asked about forever but can never be sent:
IBEISIA.sendAnnotationsAsNeeded (src/main/java/org/ecocean/identity/IBEISIA.java:3731) selects annsToSend purely on !iaAnnotIds.contains(ann.getAcmId()) — WBIA doesn't have it, so queue it.
WildbookIAM.sendAnnotations (src/main/java/org/ecocean/ia/plugin/WildbookIAM.java:264) then silently drops any annotation whose backing MediaAsset.getAcmId() == null (WildbookIAM.java:295-298, logged as a WARNING and skipped).
sendAnnotationsAsNeeded does add the backing asset to masToSend when WBIA lacks the image, but the asset registration result is not confirmed before sendAnnotations runs in the same pass — and if the asset send fails or the asset is terminally invalid, the annotation is skipped again on every subsequent pass. The identify then proceeds regardless (see the companion exception-swallowing issue), targeting an annotation WBIA was never given, and fails with code 600.
Expected Behavior
The "needs sending" predicate and the "can be sent" predicate should agree. An annotation whose MediaAsset lacks an acmId should either (a) have the image registered first and the annotation sent in a confirmed order within the same heal, or (b) be excluded from the identify's annotation lists entirely and surfaced as an actionable error — not carried into the identify as if registered.
Notes
feat(ia): WBIA annotation reconciliation sweep #1710's ensureImageRegistered heal solves the ordering problem for the background sweep (commit validity → probe → adopt → POST → commit only after confirmation); the in-request path needs the same discipline or an explicit rejection.
Found during the investigation for #1710, where it is documented as explicitly out of scope.
Current Behavior
The eligibility rules for "ask WBIA whether it has this annotation" and "actually send this annotation to WBIA" disagree, so some annotations are asked about forever but can never be sent:
IBEISIA.sendAnnotationsAsNeeded(src/main/java/org/ecocean/identity/IBEISIA.java:3731) selectsannsToSendpurely on!iaAnnotIds.contains(ann.getAcmId())— WBIA doesn't have it, so queue it.WildbookIAM.sendAnnotations(src/main/java/org/ecocean/ia/plugin/WildbookIAM.java:264) then silently drops any annotation whose backingMediaAsset.getAcmId() == null(WildbookIAM.java:295-298, logged as a WARNING and skipped).sendAnnotationsAsNeededdoes add the backing asset tomasToSendwhen WBIA lacks the image, but the asset registration result is not confirmed beforesendAnnotationsruns in the same pass — and if the asset send fails or the asset is terminally invalid, the annotation is skipped again on every subsequent pass. The identify then proceeds regardless (see the companion exception-swallowing issue), targeting an annotation WBIA was never given, and fails withcode 600.Expected Behavior
The "needs sending" predicate and the "can be sent" predicate should agree. An annotation whose MediaAsset lacks an acmId should either (a) have the image registered first and the annotation sent in a confirmed order within the same heal, or (b) be excluded from the identify's annotation lists entirely and surfaced as an actionable error — not carried into the identify as if registered.
Notes
ensureImageRegisteredheal solves the ordering problem for the background sweep (commit validity → probe → adopt → POST → commit only after confirmation); the in-request path needs the same discipline or an explicit rejection.