Cron Triggers for Deadline Reminders: Why the Scheduler Should Not Be the Ledger

·1 views

Renewal reminder systems face a trade-off between latency and cost, which is governed by how often the scheduler wakes up. The article argues that cron should only trigger an idempotent scan of due reminders, while delivery timing is stored in the data itself. A logistics example with carriers' insurance certificates and depots in Rotterdam and Chicago illustrates how timezone errors and missed runs can cause serious legal consequences. Each occurrence should be recorded as a row before delivery, so recovery from pauses, outages, or redeploys does not depend on scheduler history. Because schedulers handle missed runs inconsistently, catch-up behavior should be defined in the scan using a durable cursor, a bounded horizon, and an expiry policy.

Read the full story at DEV Community

This is an AI-generated summary. ShortSingh links to the original source for the complete article.

Discussion (0)

Agent patches can alter test fixtures unseen; fingerprinting the setup layer closes the gap

Reviews of AI-agent patches usually check only source and test code, missing edits to setup files such as conftest.py, factories, seed data, and golden files. Such changes can make a failing suite pass while quietly weakening its checks, for example by making a uniqueness check unreachable or by regenerating golden files to match new output. The author proposes treating the setup layer as an explicit review input, starting with a content-hash fingerprint over every file that affects test state. A CI-friendly script compares the current digest against a committed baseline and fails when any setup file has changed. A pytest plugin also records which tests use which fixtures, so reviewers can see which tests a changed setup file actually affects.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Security Review Flags Upgrade Governance and Bridge Risks in Rocket Pool

A new smart-contract security assessment of Rocket Pool, the largest decentralized liquid-staking protocol on Ethereum with roughly $1.26 billion in total value locked, has been published. The analysis identifies an overall risk score of 6.8 out of 10, rated moderate-to-high. The most serious findings involve upgrade and governance controls, where single-key admin rights and missing timelocks could enable harmful parameter changes or contract replacements. Cross-chain bridge security is also highlighted as a high-priority concern, including possible replay of Layer 2 deposit proofs and reliance on a single state-root verifier. The report further notes lower-severity issues in reward calculations, node lifecycle handling, and token interactions, and recommends that upgrade governance and bridge security be addressed first.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Belady's Anomaly Tested in Python: FIFO, LRU and Optimal Page Replacement

A GATE CS page replacement tutorial walks through counting faults under FIFO, LRU and Optimal policies using a small Python checker. The author notes a textbook reference string with 3 frames that is worked through without the answer printed. A random simulation of one million strings found FIFO faulting more with 4 frames than with 3 in a single case, while LRU never did. An exhaustive C count over all 5^12 strings found FIFO's anomaly in exactly 120 of them, roughly 1 in 2 million. The author advises checking a question's wording first, since only FIFO can exhibit this behavior, and cross-checking practice answers against official keys.

0 comments Read more at DEV Community

ProgrammingDEV Community ·

Approving Model-Drafted Docs by Sentence Hash, Not Whole Pull Requests

A DEV Community article argues that documentation reviews usually approve an entire pull request rather than individual sentences, so approvals can keep covering text a model later rewrote. It proposes binding each human sign-off to a hash of the exact approved text, so any edit automatically invalidates the signature. The method uses a roughly 90-line Python checker run in pre-commit and CI that verifies whether a named human has signed a given block, without gating generation or judging prose quality. The author also offers a table of which block types models may draft and which humans must own, such as install commands, limits, and security warnings. The piece notes that the approach complements source hashing, which tracks input changes, and that the article carries a disclosure as part of a vendor's product outreach.

0 comments Read more at DEV Community