Update Canary to v1.5.2#1006
Conversation
| echo "==================== INSTALLING APP ====================" | ||
|
|
||
| VERSION="${VERSION:-v1.5.0}" | ||
| VERSION="${VERSION:-v1.5.2}" |
There was a problem hiding this comment.
Are you still having issues if you don't re-define this? It should be present in the environment already.
There was a problem hiding this comment.
You're right — removed. VERSION is already injected into the install script's environment by the framework (from canary.json's latest_version), so the ${VERSION:-…} fallback was redundant. The script now just uses the framework-provided VERSION.
| services: | ||
| backend: | ||
| image: canary-backend:latest | ||
| image: schjonhaug/canary-backend:v1.5.2 |
There was a problem hiding this comment.
Could you make this a variable that gets set as part of an environment. Most apps can get down to have the only version specifier necessary be the one in the apps JSON data.
For example, you could do what mempool-docker-compose.yml does and use ${VERSION} with a .env file generated in the pre_canary.sh script (like pre_mempool.sh).
Alternatively, you could delete and re-tag the latest version of canary as latest (which you seem to be doing already) and keep the latest reference in this file.
There was a problem hiding this comment.
Went with your second suggestion and reverted these back to canary-backend:latest / canary-frontend:latest. install_canary.sh already pulls the pinned :$VERSION image and retags it as :latest, so the only version specifier left is the one in canary.json. (I didn't take the .env/${VERSION} route since the pre/runtime scripts don't receive VERSION from the framework the way install scripts do, so it'd need extra plumbing for a dynamic app — the retag path keeps it simpler.)
| tr -dc A-Za-z0-9 < /dev/urandom | head -c "$length" | ||
| } | ||
|
|
||
| service_is_enabled() { |
There was a problem hiding this comment.
These could be helpful. Do you want to move these to mynode_functions.sh?
At least move service_is_enabled() and then rename it to is_service_enabled() to match the python version. The other two I may want to remove. I'll explain in another comment.
There was a problem hiding this comment.
Moved is_service_enabled() into mynode_functions.sh (renamed to match the python is_service_enabled) and pre_canary.sh now sources it. I also dropped the other two helpers (service_is_active/service_is_available) entirely per your next comment.
|
|
||
| has_local_tx_explorer=0 | ||
|
|
||
| if service_is_available mempool; then |
There was a problem hiding this comment.
Using service_is_available() may cause a race condition on startup. A number of apps start at the same time so Canary may not realize the other apps are available because they are not yet active. I think sticking with an is_service_enabled() check only would be a better approach.
Was there a reason you had to add the check for "is-active"?
There was a problem hiding this comment.
Good catch, and thanks for the explanation. The is-active check was the tightening I added in #1004 to handle a service being stopped after Canary starts — but you're right that at startup it races against other apps still coming up. Reverted to an is_service_enabled-only check, which is why the service_is_active/service_is_available helpers are gone.
- install_canary.sh: drop redundant VERSION fallback; rely on the framework-provided VERSION (sourced from canary.json latest_version) - docker-compose.yml: reference canary-backend:latest / canary-frontend:latest instead of pinned tags; install_canary.sh already retags the pulled versioned images as :latest - mynode_functions.sh: add shared is_service_enabled() helper - pre_canary.sh: drop local service helpers, source mynode_functions.sh, and gate local explorer detection on is_service_enabled only (no is-active check) to avoid a startup race when services are enabled but not yet active
2 participants
Summary
Update Canary myNode app package to v1.5.2.
This continues the previous v1.5.1 review from #1004 and includes the fixes made in response to that feedback.
Release summary
Canary v1.5.2 rejects invalid xpub descriptors before they can create wallets that cannot sync correctly, and adds recovery handling so failed or stuck wallet records can be deleted and recreated. It also fixes Genesis wallet/address-watch syncing edge cases, and adds myNode local transaction explorer detection when Mempool or BTC RPC Explorer is available.
Upstream release
https://github.com/schjonhaug/canary/releases/tag/v1.5.2
Test plan
mynode-sdk build canary