Repository navigation
Upgrade hevy2garmin from upstream (staged; do not merge yet) - #3
Merged
Merged
Conversation
Check each pull request for terms that must not appear here
…as#748) Hevy's API sends no per-set execution time for strength sets, so in merge mode the tool assigned each set a duration itself and scaled them to the activity's length, which made every set end up the same (the reported 33 seconds) and overwrote the real per-set timing the watch had recorded. When a workout was recorded on both the watch and Hevy, keep the watch's own set and rest timing and write only the exercise names, reps and weights onto it. The watch's existing sets are already read back and backed up before the push, so this reuses them: it maps the two set lists by active-set position and overlays Hevy's identity on the active sets, keeping each set's duration and start time from the watch. When the two disagree on how many sets there were, there is no sound mapping, so the synthesized timing stands. This is on by default. A new setting, merge_preserve_watch_timing, turns it off to sync the synthesized timing as before. Done in both the Python engine and the TypeScript package, with tests.
…timing fix(merge): preserve the watch's own set timing in merge mode (drkostas#748)
The dashboard shows "Update available: N new changes since your version", with See what's new linking to the GitHub compare. GET /api/update-check compares the deployed commit with upstream main, with the saved GitHub token when there is one, and caches the answer in app_cache for 6 hours. The banner loads after the page renders; any failure means no banner. A fork from before the 9 September 2026 history rewrite compares as diverged with a merge base in the shared first commits, so for the default upstream a merge base at or before dc5905a gets the banner without a count, with the fork and README links. "No common ancestor" is kept as a fallback. Dismiss is remembered in localStorage until upstream has a newer commit. H2G_UPDATE_CHECK=off turns it off; H2G_UPSTREAM_REPO names the upstream. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoHpmqqCWbyvvXEJVaKt82
…rkostas#749) On a Vercel fork with a saved GitHub token the update banner offers Update now. POST /api/update-fork (session-gated, refused in demo and self-hosted) calls merge-upstream on the fork's default branch with the saved token, then marks the cached check as updating so the banner stops offering it until the new deployment arrives. The page polls /api/version and reloads when the deployed commit changes. A 409 or 422 is not retried: the banner links to the fork and the README's update steps. A 401 or 403 says the token needs the repo scope, and workflow when the update changes .github/workflows/. The token is never in any response. On phones the banner text takes the full width and the actions wrap below. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoHpmqqCWbyvvXEJVaKt82
…rkostas#749) A failed check (rate limited, a network error, a 5xx, or an answer it cannot read) is cached in app_cache under update_check_failure until GitHub's x-ratelimit-reset time when the failing response gave one in the future, otherwise for an hour. Until then no dashboard view asks GitHub, and there is still no banner. The failure has its own key, so it never replaces the cached result: a fresh result is still served while a failure is cached, and a stale one is left as it was. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoHpmqqCWbyvvXEJVaKt82
…ting (drkostas#749) merge-upstream answers 200 with merge_type "none" when the fork is not behind ("This branch is not behind the upstream drkostas:main."). Update now treated that as started and polled /api/version for a deployment that this call never triggered. syncFork now reports upToDate for merge_type "none"; "fast-forward" and "merge" still mean started. The banner then says the fork is already up to date (a new deployment may still be on its way) and polls nothing. The route asks GitHub again past the cached check: up to date is cached as such, and still behind (the deployment not there yet) is cached as updating, so the banner goes either way. If GitHub fails, the cached entry is marked updating. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoHpmqqCWbyvvXEJVaKt82
…ostas#749) GitHub sends retry-after (seconds) with its secondary rate limits instead of a usable x-ratelimit-reset. A failed check is now cached for retry-after when the failing response gives a positive one, else until a future x-ratelimit-reset, else for an hour. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoHpmqqCWbyvvXEJVaKt82
… sync (drkostas#749) After Update now found the fork already up to date, the banner kept its "Update available: N new changes" line above "Your fork is already up to date", which contradicted it until the next page load. In that state only the up-to-date line shows. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoHpmqqCWbyvvXEJVaKt82
drkostas#749) Once Update now finds the fork already up to date there is nothing new to see, and the link pointed at the cached check's compare. In that state the banner shows only the up-to-date line and Dismiss. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MoHpmqqCWbyvvXEJVaKt82
feat(web): tell a fork when upstream has updates, with a one-click Update now (drkostas#749)
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 8.3.0 to 8.3.4. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v8.3.4/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-version: 8.3.4 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
…/universal/vite-8.3.4 chore(deps-dev): bump vite from 8.3.0 to 8.3.4 in /universal
Bumps [vite](https://github.com/vitejs/vite/tree/HEAD/packages/vite) from 8.3.0 to 8.3.4. - [Release notes](https://github.com/vitejs/vite/releases) - [Changelog](https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md) - [Commits](https://github.com/vitejs/vite/commits/v8.3.4/packages/vite) --- updated-dependencies: - dependency-name: vite dependency-version: 8.3.4 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>
…/typescript/vite-8.3.4 chore(deps-dev): bump vite from 8.3.0 to 8.3.4 in /typescript
…e-devdep-patch ci: auto-merge Dependabot dev-dependency patch bumps
Review upstream changes before preview upgrade
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Micker71
marked this pull request as ready for review
October 23, 2026 19:02
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scope
Stages 21 upstream commits on
review/upstream-2026-10-22without changing Productionmain. Review-only PR: DO NOT MERGE YET.Confirmed safety and build checks
DEMO_MODEguard on GET/api/cron/syncpreview/review/upstream-2026-10-22as a branch ofmainMust verify before production merge
DEMO_MODE=true(confirmed by authenticated read-only diagnostic on Preview)POSTGRES_URLresolves to the Neon preview branch (endpointep-sweet-sea-bia4nk43matched in both Vercel diagnostic and Neon Computes)Important: The prior direct HTTP test against Vercel Preview returned 302 (Vercel deployment protection), not the application's 403. The green local smoke test validates application behavior in an isolated runner, but is not proof of the deployed Preview environment configuration. Do not disable Vercel protection or merge this PR as a workaround.
Temporary Preview diagnostic (remove before production merge)
/api/preview-diagnosticsauthentication and liveDEMO_MODE=true(user verified unauthorized without session and authenticated output)ep-sweet-sea-bia4nk43to Neon Preview branch Computes (matched Preview compute)web/app/api/preview-diagnostics/route.tsfrom review branch before marking PR ready