Opened 6 months ago

Last modified 3 months ago

#33365 needs_revision defect

Probe Snowflake bridge from proxy 1x a day

Reported by: cohosh Owned by: arlolra
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords: snowflake-webextension
Cc: cohosh, phw, arlolra, dcf Actual Points:
Parent ID: Points:
Reviewer: cohosh Sponsor: Sponsor28

Description

We're getting reports that the Snowflake bridge isn't reachable in #33364, but it's taking awhile for volunteers to notice because the probe check only happens once at installation or if you disable/enable the proxy.

Perhaps we can do the probe check 1x a day (e.g., when we do the stats refresh)?

Child Tickets

Change History (12)

comment:1 Changed 6 months ago by cohosh

It would be nice also to have a "Retry" button in the UI. Otherwise the user has to restart their browser or go to the addons settings page to reset it.

comment:2 Changed 6 months ago by cypherpunks

Can there also be a counter as to how many users have been helped through this extension? I have never seen a user connected to mine, so the number might as well be zero, for all I know.

comment:3 Changed 4 months ago by arlolra

Owner: set to arlolra
Status: newassigned

comment:4 Changed 4 months ago by arlolra

Keywords: snowflake-webextension added; webextension removed
Status: assignedneeds_review

Here's a branch that adds a retry button,
https://github.com/keroserene/snowflake/commits/retry

We can build on that to automatically retry after a period of time. Also, maybe the probe should always be run every once and a while, rather than just at startup?

comment:5 Changed 4 months ago by cohosh

Reviewer: cohosh

comment:6 Changed 4 months ago by arlolra

We can build on that to automatically retry after a period of time.

Quickly pushed a patch to the branch to probe once a day that I should probably have tested.

comment:7 Changed 4 months ago by cohosh

Status: needs_reviewneeds_information

It generally looks good to me, but I had a question about the structure of the last commit.

comment:8 Changed 4 months ago by arlolra

It generally looks good to me, but I had a question about the structure of the last commit.

I responded there but, in brief, these patches were about retrying at startup, as suggested in comment:4

We can refactor further to do continuous probing as a follow up. There are probably a few gotchas to think through, like resetting on successfully handling a client and maybe disabling when failing to handle a client.

comment:9 in reply to:  8 Changed 3 months ago by cohosh

Replying to arlolra:

It generally looks good to me, but I had a question about the structure of the last commit.

I responded there but, in brief, these patches were about retrying at startup, as suggested in comment:4

We can refactor further to do continuous probing as a follow up. There are probably a few gotchas to think through, like resetting on successfully handling a client and maybe disabling when failing to handle a client.

Would it be too difficult to do the refactor here with these changes? I figure we might as well and want to avoid forgetting to tackle this.

comment:10 Changed 3 months ago by arlolra

Can I merge the earlier patches in the chain though, since this is an area under somewhat active development and I'd like to reduce the chance of conflict while working on refactoring the final patch?

comment:11 in reply to:  10 Changed 3 months ago by cohosh

Status: needs_informationmerge_ready

Replying to arlolra:

Can I merge the earlier patches in the chain though, since this is an area under somewhat active development and I'd like to reduce the chance of conflict while working on refactoring the final patch?

Okay sure. Thanks!

comment:12 Changed 3 months ago by arlolra

Status: merge_readyneeds_revision
Note: See TracTickets for help on using tickets.