Storage policy chunk_concurrency is parsed as i32: an out-of-range value breaks the entire directory listing

[PLus123456]

Summary

The client deserializes the storage policy field chunk_concurrency into an i32. When the server-side storage policy holds a value larger than i32::MAX (2147483647), serde fails on the entire JSON response rather than just that field.

Because storage_policy is embedded in the file-listing response, this makes the sync root permanently unusable: registration and CfConnectSyncRoot both succeed, but no placeholder can ever be created, so Explorer shows "cloud service unavailable" on a folder that is otherwise a perfectly valid sync root. Nothing in the UI hints at the cause — you have to read the log to find it.

Environment

• Client: 0.2.0.0 (Microsoft Store package 2106abslant.Cloudreve)
• OS: Windows 11 Pro for Workstations, build 26300
• Server: self-hosted Cloudreve v4

Steps to reproduce

1. In the server admin panel, set a storage policy's chunk upload concurrency to a value above 2147483647 — e.g. 9999999999.
2. Mount that user's drive in the desktop client.
3. The sync root registers and connects without error.
4. Open the sync folder in Explorer.

Actual behaviour

The folder cannot be listed. Log:

WARN  drive::mounts: Failed to fetch user storage policies id=... error=JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 114
WARN  drive::sync:   Failed to enumerate child directory id=... directory=F:\Cloudreve error=JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 7144
ERROR drive::mounts: Failed to sync paths id=... error=Mount ... sync_group(F:\) encountered 1 error(s):
- F:\Cloudreve: JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 7144
ERROR drive::mounts: Failed to fetch placeholders id=... error=JSON error: invalid value: integer `9999999999`, expected i32 at line 1 column 7144

The last line repeats on every FetchPlaceholders callback, i.e. every time the folder is opened.

The offending payload, from GET /api/v4/file?uri=cloudreve://my:

"storage_policy":{"id":"K4Uv","name":"...","type":"local","max_size":0,"chunk_concurrency":9999999999}

Note that max_size: 0 is fine — chunk_concurrency is the only out-of-range field, and it is not even used for listing files.

Expected behaviour

One out-of-range value in an auxiliary metadata field should not take down the whole directory listing. At minimum the failure should be visible in the UI rather than only in the log.

Suggested fix

• Widen chunk_concurrency to u64/i64.
• Make storage_policy deserialization tolerant — #[serde(default)] plus a clamp, or a lenient wrapper type — so a bad value degrades to a default instead of failing the entire response. The same applies to every other numeric field in this struct.
• Server side, the admin UI accepts values the client cannot represent; validating the range there would prevent the mismatch in the first place.

Workaround

Set the storage policy's chunk upload concurrency to a small value.

[YUDONGLING]

I think the i32::MAX (2147483647) should be large enough for all the storage policy 😱
& maybe we just add a input range check for admin dashboard?

[PLus123456]

Sure, it's true. But it is still recommended to add a double check at the desktop software.