Move concurrent update error logging to debug level.

[antoine-le-calloch]

No description provided.

[Copilot]

Pull request overview

Concurrent aux-update errors were being logged as errors by the #[instrument(..., err)] attribute, creating noise during normal operation since these are expected and gracefully handled via fallback. This PR downgrades logging for ConcurrentAuxUpdate to debug level while preserving error-level logging for other failures.

Changes:

• Remove err from #[instrument] on update_aux_inner across ZTF, LSST, and DECAM workers.
• Explicitly match on the error and log ConcurrentAuxUpdate at debug level, other errors at error level.
• Remove the redundant warn! in base.rs when concurrent modification is detected.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/alert/ztf.rs	Drop err from instrument; log concurrent update at debug, others at error.
src/alert/lsst.rs	Same change applied to LSST worker.
src/alert/decam.rs	Same change applied to DECAM worker.
src/alert/base.rs	Remove redundant warn log at the source of ConcurrentAuxUpdate.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Throughput results (39374164bda0cfea3cf27ab66e0674a4d9dc334a):

New wall time	Baseline wall time	Difference
244.0	245.1	0%

[Theodlz]

@antoine-le-calloch I kind of feel like this warning/error should not show up if all was working properly, meaning instead of just silencing a genuine warning maybe we should:

• run a script to fix all the existing data in the DB, so this doesn't happen anymore
• if it still does after the DB-wide patch, investigate what's happening

[antoine-le-calloch]

@antoine-le-calloch I kind of feel like this warning/error should not show up if all was working properly, meaning instead of just silencing a genuine warning maybe we should:

* run a script to fix all the existing data in the DB, so this doesn't happen anymore

* if it still does after the DB-wide patch, investigate what's happening

@Theodlz I think you're confusing it with the other is not strictly increasing error. I have also a PR open for this one but I'm still working on it.

[Theodlz]

@antoine-le-calloch I kind of feel like this warning/error should not show up if all was working properly, meaning instead of just silencing a genuine warning maybe we should:

* run a script to fix all the existing data in the DB, so this doesn't happen anymore

* if it still does after the DB-wide patch, investigate what's happening

@Theodlz I think you're confusing it with the other is not strictly increasing error. I have also a PR open for this one but I'm still working on it.

ohhh my bad, you are right. I did mix up these 2 errors. Let me re-read this PR.

[Theodlz]

LGTM. That approach where we don't always log errors in the function and instead do it manually isn't my favorite, but it's fine here given the length of the function! Feel free to merge (once green)

[antoine-le-calloch]

LGTM. That approach where we don't always log errors in the function and instead do it manually isn't my favorite, but it's fine here given the length of the function! Feel free to merge (once green)

Yeah I agree but how can I move it to debug without doing this?

[github-actions]

Throughput results (bcd73245d81af9b45c066076e6bc2e6d4f6edf59):

Storage	New wall time	Baseline wall time	Difference
mongo	247.6	245.8	0%
s3	286.4	271.6	5.00%

[Theodlz]

LGTM. That approach where we don't always log errors in the function and instead do it manually isn't my favorite, but it's fine here given the length of the function! Feel free to merge (once green)

Yeah I agree but how can I move it to debug without doing this?

we could imagine an approach where the function that's currently raising the error (that really is just a warning) returns some Status enum instead of just Ok() (a little bit like we handle the "alert already exist" stuff, if you ever looked at that). But honestly, I don't think it's worth the extra complexity here. We can stick with what you added!