JSX incorrectly reported in dashboard summary despite no JSX activity

[moritz-grimm]

Describe the bug

The dashboard incorrectly reports several hours of JSX activity this week, even though I did not open a single .jsx file during that period. When filtering the dashboard by language "JSX", no results are shown, which contradicts the summary stats. Additionally, when filtering by each individual project I worked on, none of them show any JSX activity either.

I suspect the root cause is in the WakaTime heartbeat import: the reported JSX time almost exactly matches the time spent in a project where I exclusively write plain JavaScript (.js files). It appears that JavaScript is being misclassified as JSX during import or aggregation.

Steps to reproduce

1. Import WakaTime heartbeats via the built-in WakaTime import feature
2. Open the dashboard - JSX is listed as a language with significant tracked time
3. Filter the dashboard by language "JSX" => no results are shown
4. Filter by each individual project worked on => none of them show any JSX activity
5. Cross-reference the reported JSX duration with a JavaScript-only project => durations match closely

Expected behavior

JavaScript heartbeats should be aggregated under "JavaScript", not "JSX". The summary stats and the filtered view should be consistent, if neither filtering by language nor by individual project yields any JSX results, it should not appear in the summary at all.

System information

• Wakapi version: 2.17.2
• OS: Ubuntu 24.04.4 LTS
• Docker image: ghcr.io/muety/wakapi@sha256:71dc015036efd760ad1a7a3e52a214847c6a601d2e0c5a70fb539a69c2d4d5d2
• Database: Postgres

Additional context

The discrepancy between summary stats and all filtered views (both by language and by project) strongly suggests the misclassification happens at import time in the WakaTime heartbeat parser, while filter queries operate on the correctly stored raw data, resulting in the inconsistency.

Update: After further observation, the issue also reproduces without a WakaTime import, an entire project session was reported as JSX despite only editing a .js file. This suggests the misclassification may not be limited to imported heartbeats but could affect live tracking as well.

[moritz-grimm]

I think I found the root cause for this. Duration.Augmented() in models/duration.go uses different logic than Heartbeat.Augment() in models/heartbeat.go.

Heartbeat.Augment() checks the actual file extension of the entity:

strings.HasSuffix(h.Entity, "."+ending)

So for the mapping jsx: JSX, it only matches files ending in .jsx.

Duration.Augmented() instead looks up the language name via the Linguist table (LanguagesByExtension) and compares it to the duration's language:

langs, ok := lib.LanguagesByExtension["."+ext]
// ...
if lang := langs[0]; strings.ToLower(d.Language) == strings.ToLower(lang) {
    d.Language = targetLang
}

Since both .js and .jsx map to "JavaScript" in the Linguist table (models/lib/extensions.go:587 and :1675), the custom mapping jsx: JSX ends up matching all JavaScript durations, not just those from .jsx files.

This means any project with only .js files gets classified as "JSX" in the dashboard/summaries, even though the heartbeats correctly show "JavaScript".

A potential fix would be to align Duration.Augmented() with the existing Heartbeat.Augment() logic (matching on file extension instead of language name). The Entity field is available on the Duration struct and stays populated even when WithEntityIgnored() is used for hashing. All existing tests still pass with this change.

However, I'm not sure if the current behavior was intentional. Happy to submit a PR if you confirm this is indeed a bug.
And that said, I have very limited experience with Go, so I might be off on some of the details here