Skip to content

Conversation

@hiroshihorie
Copy link
Member

@hiroshihorie hiroshihorie commented Jul 30, 2024

  • Test local / remote urls
  • Test url updates
  • Test error handling / validation

@hiroshihorie hiroshihorie changed the title Prepare connection Prepare connection / region pinning Jul 30, 2024
// Connect sequence successful
log("Connect sequence completed")
while true {
let region = try await resolveBestRegion()
Copy link
Contributor

@lukasIO lukasIO Aug 27, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we want to await region selection on initial connection?
The other SDKs don't block here and just continue immediately in order for region manager not to have any impact on connection speed

@hiroshihorie hiroshihorie requested a review from lukasIO September 4, 2024 04:08
Copy link
Contributor

@lukasIO lukasIO left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@pblazej
Copy link
Contributor

pblazej commented Aug 8, 2025

@hiroshihorie I'm digging into the older (stale?) PRs, anything left on this one?

@github-actions
Copy link

github-actions bot commented Sep 9, 2025

⚠️ This PR does not contain any files in the .changes directory.

Copy link
Contributor

@xianshijing-lk xianshijing-lk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some nits


func shouldRequestSettings() -> Bool {
guard providedUrl.isCloud else { return false }
guard let lastRequested = state.lastRequested else { return true }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to double check, is it intentional to return true when lastRequested does not exist ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, intentional. If lastRequested is nil, no settings have been fetched yet, so we should request them. This matches JS/Android behavior.

}

func cancel() {
settingsFetchTask?.cancel()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question

should you also update the lastRequested if settingsFetchTask is being cancelled ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Intentionally not updating. Cancellation means we didn't get valid data: didn't complete the fetch. So we shouldn't block retry for 30 seconds. The next connect() should be allowed to fetch fresh region settings. 🤔

Task { [weak self] in
_ = try? await task.value
// If the task failed before it could clear itself.
await self?.clearSettingsFetchTask(if: taskId)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe I miss something, I think we call clearSettingsFetchTask(if: taskId) more than once here


await prepareAfterFailure()

let region = try await regionManager.resolveBest(token: token)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nitpick

I wonder if we should do
do {
let region = try await regionManager.resolveBest(token: token)
nextUrl = region.url
nextRegion = region
} catch {
// handle the error in some better way ?
throw error
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's probably fine as-is 🤔 Resolving regions shouldn't really fail if there's connectivity, and if it does, we probably shouldn't continue attempting to connect anyway. I believe the JS SDK has similar logic. If you have a specific suggestion, let me know 🙂

Copy link
Contributor

@xianshijing-lk xianshijing-lk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets land it asap, and make follow-up PRs if needed.

@hiroshihorie hiroshihorie merged commit c5b8cd4 into main Jan 11, 2026
25 of 28 checks passed
@hiroshihorie hiroshihorie deleted the hiroshi/prepare-connection branch January 11, 2026 11:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants