The upstream "fab" library that is currently being used is backed by the well-known Requests library, so adding both connect and read timeouts should be possible. See https://docs.python-requests.org/en/latest/user/advanced/#timeouts. The timeout=... argument would be passed to self.phab.request(...) calls in wikibugs2.phorge.PhorgeFeedReader.

In T359145#9602411, @bd808 wrote:

The timeout=... argument would be passed to self.phab.request(...) calls in wikibugs2.phorge.PhorgeFeedReader.

Ugh. I thought at first glance that it was possible to pass additional options to phabricator.Phabricator.request(...) that would make it down to the backing request, but on further examination this is not possible. Options from here are to patch the upstream library to allow this or switch away from @Legoktm's thin Conduit API wrapper to something else.

In Striker, Tool-gitlab-account-approval, Tool-phab-ban, and quite a few other apps I have rolled my own Conduit client. The modern Conduit API functionally uses the user's token as a bearer token, so implementation is fairly trivial. See https://gitlab.wikimedia.org/toolforge-repos/gitlab-account-approval/-/blob/main/src/glaab/phabricator.py?ref_type=heads as an example. I'm leaning heavily towards this locally owned solution, not because I hate working with upstreams, but more because I don't see a lot of value in the shared library approach when the implementation is this trivial.

bd808 opened https://gitlab.wikimedia.org/toolforge-repos/wikibugs2/-/merge_requests/10

phorge: Replace fab library with local client

bd808 merged https://gitlab.wikimedia.org/toolforge-repos/wikibugs2/-/merge_requests/10

phorge: Replace fab library with local client

Mentioned in SAL (#wikimedia-cloud) [2024-03-06T18:34:42Z] <wmbot~bd808@tools-sgebastion-11> Restart phorge task to pick up changes for T359145 and T127506