syntaqxA pull request's page no longer waits for its merge options. The loader awaited work's merge_choices beside everything else, and that call reads the branch's commits for the default merge messages (repos inspect_commits fetches and reads a pack from the git store every time) and asked repos whether it is behind: 6 to 10 seconds for flagon-io/g1t #39 and #41 (Server-Timing: work 9 calls, 7.5 s inside, 214 ms of it the database), long enough for the page to time out. Now the merge box opens on what the repository's settings allow, as it did when the service could not answer, and takes the service's choices, with their messages, in place when they stream in (useArrived), keeping the method picked and a dialog that is open. Merge options are asked for only for an open or draft pull request; a merged or closed one never needed them. In work, merge_choices takes whether it is behind from what was stored with its mergeability for its head as it is now, as get_pull does (behind_now, else repos), beside its settings rather than after them. Checked: cargo test for g1t-work (189), the site's typecheck and unit tests (934).e446ed4History
- ..
- advisories.rs
- code_scanning.rs
- config.rs
- deps.rs
- history.rs
- lib.rs
- manifests.rs
- overview.rs
- patterns.rs
- planning.rs
- pull_text.rs
- ranges.rs
- registries.rs
- resolved.rs
- schedule.rs
- secret_alerts.rs
- security_updates.rs
- store.rs
- suite.rs
- suite_store.rs
- summaries.rs
- supply_chain.rs
- timezones.rs
- update_store.rs
- updates.rs
- version_updates.rs
- yaml.rs