What happens
Set Max track length to 60 in Settings. The field snaps back to 20. Nothing is said, no error appears, and the value posted to the server is 1200.
It was noticed because search results kept reporting "Over 20 min" after the limit had supposedly been raised. The badge was right. The setting had never changed.
Why
Three places hold the ceiling and they disagree:
| Where |
Ceiling |
app/core/settings.py _DURATION_MAX |
3600s, 60 minutes |
static/js/catalog.js Math.min(20, ...) |
20 minutes |
settings.maxDuration.desc in all 8 tables |
"(max 20)" |
The backend has allowed 60 all along. The client refuses to send it, and the label agrees with the client.
MAX_DURATION_SEC defaults to 1200, which is the default, not the ceiling. The client appears to have copied the default and used it as a limit.
The actual defect
The duplicated constant, not the number in it.
Nothing failed. No test broke. No log line appeared. A copy of a value went stale and the only symptom was a number quietly refusing to change, which is close to the worst failure mode a setting can have: the user believes they configured something and the app behaves as if they had not.
Correcting 20 to 60 would fix today's symptom and leave the mechanism in place to do it again the next time the ceiling moves.
Fix direction
Publish the bounds from /api/settings and let the client read them. The server already clamps and returns the value it kept, and the client already writes that back into the field, so the server can simply be the single authority. The description text should interpolate the same value rather than hardcoding a number in eight languages.
What happens
Set Max track length to 60 in Settings. The field snaps back to 20. Nothing is said, no error appears, and the value posted to the server is 1200.
It was noticed because search results kept reporting "Over 20 min" after the limit had supposedly been raised. The badge was right. The setting had never changed.
Why
Three places hold the ceiling and they disagree:
app/core/settings.py_DURATION_MAXstatic/js/catalog.jsMath.min(20, ...)settings.maxDuration.descin all 8 tablesThe backend has allowed 60 all along. The client refuses to send it, and the label agrees with the client.
MAX_DURATION_SECdefaults to 1200, which is the default, not the ceiling. The client appears to have copied the default and used it as a limit.The actual defect
The duplicated constant, not the number in it.
Nothing failed. No test broke. No log line appeared. A copy of a value went stale and the only symptom was a number quietly refusing to change, which is close to the worst failure mode a setting can have: the user believes they configured something and the app behaves as if they had not.
Correcting 20 to 60 would fix today's symptom and leave the mechanism in place to do it again the next time the ceiling moves.
Fix direction
Publish the bounds from
/api/settingsand let the client read them. The server already clamps and returns the value it kept, and the client already writes that back into the field, so the server can simply be the single authority. The description text should interpolate the same value rather than hardcoding a number in eight languages.