Go handler — partial DB open leaves the function permanently degraded

handler.go lines 529–545 (the initDBs function):

cityDB, err = geoip2.Open(filepath.Join(dir, "GeoLite2-City.mmdb"))
if err != nil {
    initErr = err
    log.Printf("ERROR opening GeoLite2-City.mmdb: %v", err)
    return
}
asnDB, err = geoip2.Open(filepath.Join(dir, "GeoLite2-ASN.mmdb"))
if err != nil {
    initErr = err
    log.Printf("ERROR opening GeoLite2-ASN.mmdb: %v", err)
}

If cityDB opens successfully but asnDB fails, initErr is set while cityDB is valid and open. The Handle function then gates on initErr != nil and returns 500 for every subsequent request, permanently, because sync.Once will not retry. The function is fully broken even though city-level enrichment would work fine.

Since both databases are embedded in the image at build time, the failure scenario is uncommon in production, but the code will mislead readers about how to handle partial initialisation. The fix is either to treat the two databases as independent (check cityDB != nil / asnDB != nil per lookup, which the rest of the code already does) and not use a single initErr, or to keep initErr but set it only when the function is completely unable to serve any lookups.

Python handler — search window vs. cron interval mismatch is unexplained

handler.py line 410:

hits += search_hn(query="serverless", tags=tags, num_hours=24)

The function is scheduled every 15 minutes but searches the last 24 hours on every invocation. This is safe because the database deduplicates hits, but the first invocation will attempt to post up to ~100 items (50 per story/comment page) that accumulated over the previous day. The post does not mention this and readers following along may be surprised by a burst of Discord notifications on first deploy. A brief callout that the wide window is intentional and that deduplication absorbs the overlap would prevent confusion.

Node.js handler — master key is read from disk on every invocation

handler.js lines 142–149 (loadMasterKey): the key is read and validated synchronously on each request. For a tutorial this is low-stakes, but the post presents the handler as production-quality. If the post is meant to model best practice, a note acknowledging the per-request I/O (or caching the key at module load) would be consistent with the care taken elsewhere in the handler.

Editorial — WIP title

The PR title is "WIP: How To Train Your Agent blog post". The post reads as substantially complete; if there are specific sections still in progress, flagging them explicitly (e.g. with a TODO comment in the draft or a checklist item in the PR description) would help reviewers know what to focus on.