repo downloads do not work on v0.2.7

[hgy59]

neither to download in the package center nor the manual download works

[publicarray]

I'll revert the changes (back to v0.2.6), I did testing locally but I guess I wasn't thorough enough

[publicarray]

Revert is completed and I can download packages, How about you @hgy59

[hgy59]

@publicarray thanks, it's working again

[mreid-tt]

@hgy59, @publicarray, I've been investigating the differences between the catalog returned by our server and Synology’s server using the files in this directory:

$ ls -al /run/synopkg/pkglist/
total 516
drwxr-xr-x 2 root root    140 Feb 20 21:25 .
drwxr-xr-x 3 root root     80 Feb 20 21:09 ..
-rw------- 1 root root  25979 Feb 20 21:25 installed.enu
-rw------- 1 root root    965 Feb 20 21:23 otherserver.filtered.enu
-rw------- 1 root root   2078 Feb 20 21:23 otherserver.raw.enu
-rw------- 1 root root 238635 Feb 20 21:24 synoserver.filtered.enu
-rw------- 1 root root 246385 Feb 20 21:09 synoserver.raw.enu

Synology’s catalog includes both a packages section and a beta_packages section, whereas our server only returns a packages section. I initially suspected this might explain why beta packages from our server don’t appear in DSM 7’s Package Center as they do in DSM 6.

To test this, I implemented the required changes in my branch (main...mreid-tt:spkrepo:add-catalog-beta_packages) and confirmed that the expected output was generated. However, neither DSM 7.1 nor 7.2 recognized this information to display community beta packages.

Based on these findings, I believe that DSM versions beyond 6 no longer support displaying beta packages from third-party sources. Furthermore, due to how our queries work—fetching the latest build and either including or excluding betas—if the latest build is a beta version, it won’t appear in DSM 7’s Package Center when beta packages are included in the request.

I verified this further by removing the line that sets entry["beta"] = True, and in doing so, the latest beta version of Monit did appear in the Package Center (albeit without the beta label).

Next Steps

Given this behavior, how should we proceed? My recommendation is to restrict the beta function for DSM 7 users so that it only returns the latest non-beta packages. This would:

• Ensure that packages with both beta and non-beta versions don’t become invisible to DSM 7 users.
• Maintain full functionality for DSM 6 users, where beta packages are still supported.

I believe this is the root cause of the issue described in #141 (comment), and a fix has been proposed in #145.

Let me know your thoughts! 🚀

[mreid-tt]

@hgy59, I’d appreciate your feedback on the above, as well as any further details on the symptoms observed when this issue was first reported. Could you specify which package(s) failed to download and any error messages or other symptoms encountered? I’d like to fully resolve this before the next release, but I haven’t been able to fully reproduce the issue.

[hgy59]

@hgy59, I’d appreciate your feedback on the above, as well as any further details on the symptoms observed when this issue was first reported. Could you specify which package(s) failed to download and any error messages or other symptoms encountered? I’d like to fully resolve this before the next release, but I haven’t been able to fully reproduce the issue.

AFAICR all packages were affected, and download in package center and manual download had an 404 (not found) error.

[mreid-tt]

AFAICR all packages were affected, and download in package center and manual download had an 404 (not found) error.

This is unfortunate, as it doesn’t give me much to go on. @publicarray, unless we have more details, I don’t see any code changes that would have caused this behaviour. Without a way to clone the production environment and reapply the release, I’d need access to the logs from when this occurred to diagnose further.

[mreid-tt]

Hey @publicarray, when you have a moment, could we try another release with the latest changes? I’d like to get the production server updated. I’m happy to be on standby to help with testing whenever you're ready.

[publicarray]

Thanks, not tonight unfortunately are you available on the 17th around this time? @mreid-tt

[mreid-tt]

Thanks, not tonight unfortunately are you available on the 17th around this time? @mreid-tt

Yes, I can make myself available. No probs and we can always coordinate on Discord.

[mreid-tt]

Hey @publicarray, thanks for troubleshooting this with me earlier today. Based on the logs provided from a brief switchover to v0.2.7, the issue seems to be as follows:

Issue Update (v0.2.6 → v0.2.7 Deployment Breakage)

---

1. Background

• Symptom: After upgrading from v0.2.6 to v0.2.7, the download endpoints began returning 404s and the catalog endpoint no longer honors Accept: application/json—always rendering HTML instead.
• Minimal diff: v0.2.6 → v0.2.7 changes only bump the Docker image tag (and thus all dependencies) and adjust one DB filter (report_url IS NULL → IS NULL OR = "").

2. Dependency Changes

• Werkzeug was updated 3.0.1 → 3.1.3 (bug-fix–only in 3.1.x; no new routing behavior)
• Flask was bumped 2.3.3 → 3.1.0, pulling in Werkzeug 2.2.3+ behavior changes (strict-slash redirects) and the 2.3.0 part_isolating=False default for converters matching /.

Key takeaway: Neither the 3.1.x bug-fix releases nor Flask 3.1.0 introduce breaking changes in route matching beyond what was already present in Werkzeug 2.2.3/2.3.0.

3. Routing & Proxy Configuration

• Nginx is correctly proxying /… to app:8000 without any extra location blocks or rewrite rules.
• No change to Flask route definitions or URL patterns between 0.2.6 and 0.2.7.
• %5B…%5D (bracket‐encoding) and trailing-slash handling were considered but ruled out as root causes in this case.

4. Root Cause Identification

• Unfortunately a root cause has not been identified based on the evidence.
• Attempts to re-create the environment in Docker have proven to be challenging as the deployment never seems to complete on my Synology (see: docker_setup_log.txt)

5. Next Steps

• We need to find a way to reproduce the issue in a test environment to better understand the issue.

• Optional fixes (to accommodate Flask/Werkzeug behavior):

  • app.url_map.strict_slashes = False (proposed in Routing: Disable strict-slash matching for compatibility #150)
  • urllib.parse.unquote() on filename for percent-decoding

---

EDIT: Another solution to consider was proposed in https://github.com/SynoCommunity/kb/pull/1

[mreid-tt]

Hey @publicarray — thanks again for your help this morning. We discovered that our production setup uses subdomain‐based blueprints (e.g. packages.synocommunity.com), and after PR #142 bumped Flask to 3.1.0, the default subdomain matching was disabled.

I’ve opened PR #151 to introduce a new SUBDOMAIN_MATCHING flag in our config so you can toggle subdomain routing on or off per environment. Here’s what the toggle looks like in my test setup:

• SUBDOMAIN_MATCHING=False (default):

$ curl -H "Host: packages.synocommunity.com" 'http://127.0.0.1:5000/?package_update_channel=beta&build=24922&language=enu&major=6&micro=2&arch=x86_64&minor=2'

<!DOCTYPE html>
  <HTML of root page>

• SUBDOMAIN_MATCHING=True:

$ curl -H "Host: packages.synocommunity.com" 'http://127.0.0.1:5000/?package_update_channel=beta&build=24922&language=enu&major=6&micro=2&arch=x86_64&minor=2'
{"keyrings": [], "packages": [{"changelog": "1. Update monit to v5.29.0<br/>2. Update OpenSSL to v1.1.1l", "conflictpkgs": null, "deppkgs": null, "desc": "Monit is a small Open Source utility for managing and monitoring Unix systems. Monit conducts automatic maintenance and repair and can execute meaningful causal actions in error situations.", "dname": "Monit", "download_count": 0, "link": "http://packages.synocommunity.com/monit/10/monit.v10.f15047%5Bapollolake-avoton-braswell-broadwell-broadwellnk-bromolow-cedarview-denverton-dockerx64-geminilake-grantley-purley-kvmx64-v1000-x86-x86_64%5D.spk?arch=x86_64&build=24922", "maintainer": "SynoCommunity", "md5": "2f9ca4f98695c96cad3937e48524227f", "package": "monit", "qinst": false, "qstart": false, "qupgrade": true, "recent_download_count": 0, "thumbnail": ["http://packages.synocommunity.com/monit/10/icon_72.png", "http://packages.synocommunity.com/monit/10/icon_256.png"], "version": "5.29.0-10"}]}

$ curl -H "Host: packages.synocommunity.com" -O 'http://127.0.0.1:5000/monit/10/monit.v10.f15047%5Bapollolake-avoton-braswell-broadwell-broadwellnk-bromolow-cedarview-denverton-dockerx64-geminilake-grantley-purley-kvmx64-v1000-x86-x86_64%5D.spk?arch=x86_64&build=24922'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 2180k  100 2180k    0     0  28.6M      0 --:--:-- --:--:-- --:--:-- 29.1M

Next, I’ll merge it into main and we can deploy the updated version to production. Let me know if you have any questions.