Which dedupe strategy fits Deta Space scheduled actions for low-noise alerts?

Answer

Use Deta Base for dedupe state, not Drive. Use a per-install composite key install_id:alert_type:entity_id and store last_state, last_alerted_at and consecutive_breaches. Alert on a healthy→breached transition or after N consecutive breaches, and suppress re-alerts until the condition clears for a configurable clear window. Per-installation state is sufficient for user-scoped notifications because each Space install has its own Base/Drive namespace.

Scheduled action frequency limits for Spacefile cron are version-sensitive. Verify the current minimum interval and Base write rate in the official platform documentation before assuming sub-minute checks are allowed.

Confirmed facts

• Deta Space scheduled actions are declared via Spacefile and run as serverless functions with no built-in alerting subsystem. All dedupe logic must be implemented in app code using Base or Drive.
• Base is key-based record storage; Drive is file-oriented. For small metadata checks in a cron run, Base provides lower latency reads/writes for a dedupe record.
• Each Space install is isolated. Per-installation state is correct for per-user notifications. Cross-user deduplication would require a shared Base, which is not the default per-install model.

Likely explanation and practical pattern

Drive adds unnecessary file I/O and versioning complexity for a tiny state record. Base upsert semantics can make the check-then-write idempotent within a single scheduled invocation, reducing duplicate alerts on retries.

Key structure to handle flapping:

• Key: f"{install_id}:{alert_type}:{entity_id}"
• Fields: last_state boolean, last_alerted_at ISO timestamp, consecutive_breaches int

Cooldown / hysteresis pattern:

1. Read the dedupe record for this key.
2. Evaluate current condition.
3. If condition is false: reset consecutive_breaches to 0 and update last_state to false. This clears the suppression window.
4. If condition is true: increment consecutive_breaches. Alert only if last_state was false and consecutive_breaches >= M, or if last_alerted_at is older than a re-alert cooldown and the condition has persisted.
5. On alert, write last_state=true, last_alerted_at=now, keep consecutive_breaches.

This gives transition detection plus persistence requirement, avoiding noise when the metric oscillates around the threshold.

Steps needed for this case

1. Review your current Spacefile schema for cron triggers and confirm the scheduled action entry point and available environment variables at runtime.
2. Create a Base collection for alert dedupe with the composite key above.
3. Implement the read-evaluate-write flow with consecutive breach count and clear window.
4. Simulate flapping in a test install to observe suppression and reset behavior.

One missing detail that changes the recommendation: what minimum cron interval is currently allowed for your Spacefile scheduled action and is the alert scope per-install or global across installs? The interval determines how fine-grained M consecutive runs can be, and global scope would require a shared Base instead of per-install isolation.