fix: update download_settings host changes without re-saving the main host

[FunLay123]

Summary

When a host is used as another host's xhttp download_settings, editing that host alone did not update the main host's cached data. Now, saving a host also refreshes every host that points to it as their download_settings.

Type of change

• Bug fix
• New feature
• Breaking change
• Refactor / cleanup
• Documentation
• Tests / CI

Checklist

• I tested the change locally or explained why it cannot be tested.
• I added or updated tests for behavior changes.
• I updated documentation, translations, or examples if needed.
• I checked database migrations when models or schema changed.
• I did not include secrets, tokens, private keys, or unrelated changes.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 934ae04b-a7bb-4c20-a110-bbc813c2af7a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[M03ED]

its better to have a query param for get_hosts and only get hosts that have download settings we want to change instead of checking all (at least for PostgreSQL this is possible)

[FunLay123]

@M03ED Fair point, but I don't think it's worth the added complexity here. Hosts aren't a high-cardinality table like users — realistically dozens, maybe a couple hundred on the largest setups — and this query only runs when an admin explicitly saves a host, not on the subscription-serving hot path. A SQL-level filter would also need separate handling per DB dialect. Happy to remake if host counts become a real problem, but for now I'd rather keep the simple way.