Ignore unknown monitoring metrics message 493 until fields are mapped

[deewhyarc-glitch]

Summary

While importing newer Garmin monitoring / HRV FIT files, I hit an unknown metrics message (unknown_493) and initially tried persisting it in a new monitoring DB table. That turned out to be the wrong tradeoff: it forces a monitoring DB schema bump without actually knowing what the fields mean.

The safer behavior appears to be:

• parse the file successfully
• ignore / log unknown_493
• do not fail import or require a DB schema change until the field semantics are understood

What I observed

I pulled a Garmin export archive for 2026-02-26 and found *_METRICS.fit files containing unknown_493 records.

Those records are not random garbage. They look like structured 15-minute bucketed metrics with FIT-epoch start/end times and several HR/stress-like derived values. But I could not confidently map the fields to known Garmin metrics yet.

Examples from the archive:

• two *_METRICS.fit files contained unknown_493
• each file had 46 records
• each record covered a 900-second bucket
• some fields look HR-like (unknown_12, unknown_14, unknown_16)
• some look stress / derived-load-like (unknown_3)
• some look like state/snapshot values or balances (unknown_8, unknown_10, unknown_15, unknown_17)

Problem

If local code tries to persist unknown_493 in a new monitoring table before the fields are understood, the monitoring DB version has to be bumped. That causes existing users to hit schema mismatch failures during import / analyze unless they rebuild the DB.

In my case, the bad outcome was repeated errors like:

DB: garmin_monitoring version mismatch. The DB schema has been updated. Please rebuild the garmin_monitoring DB.

Suggested fix

Short term, I think GarminDB should treat unknown_493 as optional / ignorable:

• add a handler that logs the message at debug level
• do not persist it yet
• do not fail import because of it
• avoid schema churn until the values are mapped properly

That keeps imports working on newer files without committing to a table design that may be wrong.

Why I’m filing this

I do not yet know what these values actually are or whether they’re useful enough to store. But they seem worth documenting / investigating, and in the meantime the importer should stay resilient.

If useful, I can share sample extracted field payloads from the 2026-02-26 archive in a follow-up comment.