Running a scan on a single container should display appropriate "scanning" state not "updating"

[begunfx]

When running a scan on a single container I see "updating" as the state. This seems in accurate to me. Feels like the display should be "scanning" to better match what the container is doing at the time.

See video below:

Screen.Recording.2026-04-20.at.11.20.31.AM.mov

[begunfx]

Additional note. This doubles as a bug. I knew there was an update available for changedetection.io. When I ran the scan, I got an email that a new container was available, but no pushover notification AND no update available showing in the containers view or updates available widget on the dashboard. Also the email notification was incomplete. See below:

- Container datavault_ChangeDetection running with can be updated to

No hostname or tag info

[scttbnsn]

Thanks for the detailed report — rc.13 has fixes for two of the three things here.

1. "Updating" during a scan → now "Scanning"
The row status and the chip now read Scanning while a scan is in flight, with a spinner icon and an info/neutral tone (not the warning tone used for real updates). The Update / Stop / Restart / More buttons no longer dim out during a scan either — a scan is a lightweight recheck and shouldn't lock the row. Under the hood the action tracker now records what kind of action is running per container (update / scan / lifecycle / delete) instead of just whether one is running, so the UI can react appropriately.

2. No Pushover notification on scan-triggered updates → fixed
Single-container scans (POST /:id/watch) and targeted multi-container scans only fired the per-container event; they never fired the batch event. Batch-mode triggers like Pushover only listen to the batch event, so they silently skipped scan-triggered updates. The scheduled bulk scan always emitted the batch event, which is why Pushover worked for automatic scans but not the manual ones you ran. Both manual paths now emit the batch event after the per-container event, so Pushover (and any other batch-mode trigger) will fire on manual scans in rc.13.

3. Incomplete email body (Container datavault_ChangeDetection running with can be updated to) — still investigating
The simple template on our side pulls from container.updateKind.{kind,localValue,remoteValue}. All three fields blank means updateKind itself was likely undefined on the snapshot that went to dispatch — which shouldn't happen with the computed property wired. I couldn't reproduce it here, and nothing in the notification/template code path between rc.10 and rc.13 obviously regressed it. Once rc.13 is in your hands, could you try another scan on changedetection.io and share the full email body if it still renders blank? A screenshot of the full email plus your SMTP trigger config would help narrow it down.

Will post again when rc.13 is tagged.

[begunfx]

Please see the following video on triggering a scan for a single container. The "scanning" spinner is showing after we trigger the container but is completely disconnected from the container that triggered it. Then eventually the notification comes up indicating the scan had started for the given container. I would recommend showing the scanning state at the container/row level so it stays with the container that is scanning.

https://drive.google.com/file/d/15-ZmPy1cEWyHt2sRoxb8Na9A-hpTh-MW/view?usp=sharing

[scttbnsn]

Quick status — rc.15 ships two fixes here:

• Single-container scan firing batch triggers — fixed in rc.13 (623a9724) so a single-container scan now dispatches Pushover/email/etc. through the batch path the same way a full scan does.
• "Updating" chip on the wrong row during a scan — the per-row scanning chip is now anchored via the SSE containerId payload (5a1d9e29 in rc.15) instead of inferring from row order, which is what was causing the chip to attach to a sibling row in your video.

If your recording was against a build before rc.15, please retest once v1.5.0 lands (going out shortly) — the chip should now stay locked to the container actually being scanned.

For the incomplete email body (blank hostname/tag) — could you confirm whether that still reproduces on rc.15? If yes, an example of the rendered email + the SMTP trigger config would help us track it down separately.

[scttbnsn]

Quick follow-up — after rewatching your video closely I spotted a third bug we hadn't accounted for. The chip floating in the row gutter (separate from the wrong-row anchoring issue) is a CSS positioning bug: the overlay chip is absolutely-positioned and depends on a containing block on the row, which scanning rows weren't getting (the mechanism was tied to the update-lock state, which scan deliberately doesn't trigger). Without that anchor the chip escaped the table layout and rendered in viewport-fixed coordinates — exactly the gutter-float you captured.

Just landed the fix in ac2765c3 (a new dd-row-scanning class that applies the containing block without locking the row). v1.5.0 will include all three fixes now — rc.13's batch-trigger fix, rc.15's SSE anchoring, and this CSS pin. Thanks for the recording, it made the third bug obvious.

[begunfx]

I'm trying to provide as many videos as possible since I think it will help close the loop of understanding the problem/bug in question. As long as you see value in doing that I will continue. 👍

[scttbnsn]

Yeah the videos help a lot!

[scttbnsn]

Verified this locally on the current rc branch. Single-container scans now show Scanning on the same row, not Updating, stay anchored during scroll in desktop and narrow views, and the bulk scan path still dispatches correctly.

Closing this as fixed for v1.5.0.