Community Trends shows stale star counts while Star History is correct

[djdarcy]

Problem

The Community Trends chart shows stale star counts while the Star History chart on the same page shows correct, updated values.

Observed on: https://dazzleml.github.io/comfyui-triton-and-sageattention-installer/stats/#community

Star History chart (correct):

• Feb 25: 79 stars
• Feb 26: 80 stars
• Feb 28: 82 stars

Community Trends chart (stale):

• Feb 26: 80 stars
• Feb 27: 80 stars (should be 81?)
• Feb 28: 80 stars (should be 82)

The Star History chart uses GitHub's per-star created_at timestamps (Events API), so it reflects reality. The Community Trends chart uses dailyHistory[].stars from state.json, which is only written for today's entry in the workflow (line 330: if (dateStr === todayStr)).

Likely cause

The workflow writes entry.stars = state.stars only when dateStr === todayStr. If the workflow runs and the star count changes between runs, past entries keep whatever value was written when they were "today." This is by design — stars are point-in-time snapshots, not retroactive.

However, the discrepancy suggests the ComfyUI Triton deployment's workflow may not be running the latest version. The repo hasn't been fully updated with local changes, which could mean:

• An older workflow version that writes stars differently (or not at all for some entries)
• The todayStr calculation producing a mismatch with the dailyHistory date format
• The workflow running but star metadata not being fetched/written correctly

Note

The ComfyUI Triton deployment is not fully caught up with local GTT changes, which may be the primary contributor. This issue tracks the symptom to verify once the deployment is updated.

Proposed Solution

1. Verify the deployed workflow version on ComfyUI Triton — check if it matches the latest GTT workflow
2. If workflow is outdated: Update via ghtraf init --update (once available) or manual copy
3. If workflow is current: Investigate whether the star fetch (repo metadata at line 248–252) is failing silently or whether the date matching logic has a gap
4. Consider: Should Community Trends interpolate star values from the Star History data when dailyHistory has gaps? Star History uses per-star timestamps and is authoritative — it could backfill d.stars for entries where the workflow didn't capture the value.

Acceptance Criteria

• Identify root cause (stale workflow vs logic bug vs data gap)
• Community Trends star line matches Star History data for the same dates
• If the fix requires a workflow update, document which version resolves it
• If a dashboard-side interpolation is added, it gracefully handles missing star data

Related Issues

• Refs Community Trends chart shows negative y-axis for Stars #25 — Community Trends negative y-axis for Stars (same chart, different bug)
• Refs Port delta-dedup workflow fix to NCSI Resolver and ComfyUI Triton #32 — Downstream port (ComfyUI Triton needs workflow updates)

[djdarcy]

Root Cause Analysis (from #57 investigation)

Confirmed Root Cause

The two charts use different data sources:

• Star History (renderStarChart()) fetches live stargazer events from GitHub API (/repos/.../stargazers with star timestamps). Real-time, always correct.
• Community Trends (renderCommunityTrends(state.dailyHistory)) reads the stars field from dailyHistory[] in state.json. These are point-in-time snapshots.

The workflow at line 330 only writes stars for today:

if (dateStr === todayStr) {
  entry.stars = state.stars || 0;
  entry.forks = state.forks || 0;
  entry.openIssues = state.openIssues || 0;
}

Each past entry retains whatever star count existed when that day was "today". Stars are monotonically increasing, so past entries always under-report compared to current reality.

Recommended Fix

Use Math.max (consistent with the project's "merge upward, never erase" principle):

// Stars and forks are monotonic — always use the highest known value
entry.stars = Math.max(entry.stars || 0, state.stars || 0);
entry.forks = Math.max(entry.forks || 0, state.forks || 0);
// Issues fluctuate — keep today-only snapshot
if (dateStr === todayStr) {
  entry.openIssues = state.openIssues || 0;
}

This corrects stale historical entries on next workflow run without overwriting valid data.

Cross-repo

Same bug exists in both repos (identical workflow code):

• comfyui-triton — Bug: Community Trends chart shows stale/flat star data DazzleML/comfyui-triton-and-sageattention-installer#28
• github-traffic-tracker — this repo (Community Trends shows stale star counts while Star History is correct #51)