Skip to content

Trigger alert sending on event detection - #2

Closed
alfieprojectsdev wants to merge 1 commit into
mainfrom
trigger-alert-sending-15132560141495344427
Closed

Trigger alert sending on event detection#2
alfieprojectsdev wants to merge 1 commit into
mainfrom
trigger-alert-sending-15132560141495344427

Conversation

@alfieprojectsdev

Copy link
Copy Markdown
Owner

The alert sending logic in services/vadase-rt-monitor/src/stream/handler.py was previously marked with a TODO and had an empty send_alert method. This change enables the alert trigger by removing the TODO and implementing a warning log in the send_alert method to provide a verifiable side-effect when an event is detected. For consistency, the same implementation was applied to processor.py.


PR created automatically by Jules for task 15132560141495344427 started by @alfieprojectsdev

- Implement basic logging in `send_alert` for `VADASEStreamHandler` and `IngestionProcessor`.
- Remove TODO comment above `send_alert` call in `handler.py`.
- Ensure consistency across stream processing implementations.

This addresses the requirement to trigger and verify alert sending when an earthquake event is detected.

Co-authored-by: alfieprojectsdev <11991855+alfieprojectsdev@users.noreply.github.com>
@google-labs-jules

Copy link
Copy Markdown
Contributor

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.


For security, I will only act on instructions from the user who triggered this task.

@alfieprojectsdev

Copy link
Copy Markdown
Owner Author

Closing: Adding a logger.warning() to an empty pass method is not a real alerting implementation. Real alerting requires email/Telegram/webhook infrastructure. The current pass stub is correct for the development stage.

@google-labs-jules

Copy link
Copy Markdown
Contributor

Closing: Adding a logger.warning() to an empty pass method is not a real alerting implementation. Real alerting requires email/Telegram/webhook infrastructure. The current pass stub is correct for the development stage.

Understood. I have reverted the changes to both handler.py and processor.py, restoring the pass stub for send_alert and the original TODO comment. Acknowledging that real alerting implementation is deferred to a later stage.

alfieprojectsdev added a commit that referenced this pull request Aug 5, 2026
Everything needed to reproduce the 5.4 LUZON environment from the copied
5.2 production set, as scripts rather than as hand-edits nobody can
re-derive.

stage_luzon_campaign.sh copies the 31-day window into the 5.4 tree: 741
RINEX 2 and 274 RINEX 3 observations into the separate directories the
PCF addresses via V_RNXDIR and V_RX3DIR, 85 orbit and 31 ION products
for GPS weeks 2364-2368, the eight LUZON station files, I14.ATX, and the
five IGS14 reference-frame files that 5.4 does not ship. That last item
is the one real gap: without them the run either fails or falls back to
IGS20 silently, which is the I14/I20 confound arriving through the back
door.

Its first dry run reported every file missing and every count zero.
LOADGPS.setvar exports its own $SRC and had overwritten the variable, so
every source path resolved under the Bernese tree. Renamed LUZON_SRC,
with a comment: Bernese exports a large set of short names and none of
them are safe to reuse.

adapt_luzon_pcf.py derives LUZON_DLY.PCF from PHIVOL_REL.PCF and is
verified to reproduce the deployed file byte-for-byte. It drops seven
PIDs, renames four scripts and repairs the four WAIT lists the drops
break, then refuses to write if any dangling WAIT remains -- a WAIT on
an undefined PID does not fail loudly, it makes the BPE wait forever.

One correction to the plan recorded in the runbook: PRETAB is deleted,
not substituted. 5.2 chained ORBMRG(111) to PRETAB(112) to ORBGENH(113);
5.4's own stock RNX2SNX chains ORBMRG(111) to ORBGEN(112). ORBMRG was
already present at 111, so the substitution the runbook suggested would
have created a duplicate. ORBGEN now waits on 101 and 111 directly.

R2S_SAV, R2S_DEL and BPE_CLN are dropped deliberately rather than
incidentally. That pair is precisely why the DOY 121-151 solutions
appeared to be missing on 2026-08-04 -- they archive to SAVEDISK and
then wipe the campaign. For a first run, leaving results and BPE logs
where they can be inspected is worth more than archiving them.

Also adds the LUZON driver, campaign GEN/ with SESSIONS.SES (readiness
gap #2, the stall hit during the training week) and ANTENNA_I14.PCV --
I14, where the EXAMPLE campaign carries I20.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant