Client still falls back to source when server is overloaded, even with both enableBackToSource=false and disableBackToSource=true configured

[simplecoka]

Bug report:

When the client is configured with both

client.config.scheduler.enableBackToSource: false
client.config.proxy.disableBackToSource: true
the client still falls back to the source server if the source server is overloaded or unavailable. This results in unwanted extra load on the origin, effectively bypassing the intended back‑to‑source protection.

Expected behavior:

The client should not attempt to fetch directly from the source at any time when both flags are set. Instead:

It should either fail the download gracefully,
Or enter a controlled retry/back‑off loop.
This would protect the origin system from overload.

How to reproduce it:

Deploy Dragonfly with the following relevant settings:
client:
config:
scheduler:
enableBackToSource: false
proxy:
server:
disableBackToSource: true
Overload or stop the source server service (simulate high load/failure).
Trigger a client download task (e.g., large artifact via proxy).
Please make sure that the client attempts direct download from the origin even though enableBackToSource=false and disableBackToSource=true.

Environment:

• Dragonfly version: scheduler & manager 2.3.2 client & seed v1.0.3
• OS: Ubuntu 22.04
• Kernel (e.g. uname -a): 5.15.0-124-generic
• Others:

[CooooolFrog]

This appears to be caused by an incorrect configuration example in the documentation. The configuration name is incorrect. The client's back source control configuration is client.config.schedule.disableAutoBackSource, not client.config.scheduler.enableBackToSource.
Please try correcting this configuration, restart the client, and observe whether back-to-source behavior is as expected.

[CooooolFrog]

By the way, the client currently triggers data back-to-source in two situations.

1. The client connection to the scheduler times out, and the client deems the Scheduler unavailable. To avoid download failures, it proactively triggers a back-to-source. This can be disabled using the configuration described above.
2. The scheduler proactively instructs the client to back-to-source using its scheduling policy. Currently, there's no configuration to prevent this.

Your actual need is to prevent the client from back-to-source when the source service is under high load, thus achieving back pressure. You can achieve this indirectly using the following configuration:

1. Disable proactive back-to-source client behavior, as described above.
2. Use the Scheduler configuration to limit the number of clients that can back-to-source a single task at a time. You can do this by lowering the value of scheduler.config.scheduler.backToSourceCount.