Xd, Heisenbugs happen yep. Anytime (only did a quick scan of the code and did not see anything wrong).
On 07/13 17:11, Roy Smith wrote: > Well, I know this sounds like some bad IT help desk joke, but after banging > my head against this for a good part of today, I ended up reinstalling it and > the problem went away. I'll probably never know exactly what was wrong. > Thanks anyway for taking a look. > > > On Jul 13, 2026, at 7:50 AM, David Caro <[email protected]> wrote: > > > > Can you share the source code for the tool to check it out? > > > > (and update the toolsadmin page with the repo if it's in a repo, remember > > that > > all code running has to be publicly available, > > https://toolsadmin.wikimedia.org/tools/id/fac-summary-bot). > > > > Thanks! > > > > On 07/13 07:40, Roy Smith via Cloud wrote: > >> I have a job I run under cron on toolforge: > >> > >>> toolforge jobs run fac-summary-bot --command > >>> $HOME/fac-tools/toolforge/bot.sh --image python3.11 --schedule "*/15 * * > >>> * *" --timeout 300 > >> > >> > >> It runs fine, but what I don't understand is that it logs output to > >> fac-summary-bot.out that looks like: > >> > >>> https://prosesize.toolforge.org/api/en.wikipedia.org/Mike%20Enzi > >>> {'prose_size': 23337, 'word_count': 3800, 'references': 5976} > >> > >> > >> Which looks like a request/response pair requests (or urllib) would have > >> logged from: > >> > >>> def prose_size(self) -> int: > >>> "Return the readable prose size in words." > >>> url = "https://prosesize.toolforge.org/api/html"; > >>> headers = { > >>> "user-agent": f"fac_tools ({argv[0]})", > >>> "content-type": "test/html", > >>> } > >>> r = requests.post(url, headers=headers, data=self.parsoid_html) > >>> r.raise_for_status() > >>> data = r.json() > >>> return data["word_count"] > >> > >> except that I never turned on logging for these libraries. I've verified > >> that these have no logging configured by dumping the config with > >> logging_tree <https://pypi.org/project/logging-tree/>: > >> > >>> o<--"requests" > >>> | Level NOTSET so inherits level WARNING > >>> | Handler <NullHandler (NOTSET)> > >> > >> > >>> o<--"urllib3" > >>> Level NOTSET so inherits level WARNING > >>> Handler <NullHandler (NOTSET)> > >> > >> I cannot reproduce this outside the toolforge environment, nor can I > >> reproduce it when I shell into the krb backend and run it manually. As > >> far as I can tell, it only happens when run by cron under toolforge. > >> Anybody have a clue what might be going on? > >> > > > >> _______________________________________________ > >> Cloud mailing list -- [email protected] > >> List information: > >> https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/ > > > > > > -- > > David Caro > > SRE - Cloud Services > > Wikimedia Foundation <https://wikimediafoundation.org/> > > PGP Signature: 7180 83A2 AC8B 314F B4CE 1171 4071 C7E1 D262 69C3 > > > > "Imagine a world in which every single human being can freely share in the > > sum of all knowledge. That's our commitment." > -- David Caro SRE - Cloud Services Wikimedia Foundation <https://wikimediafoundation.org/> PGP Signature: 7180 83A2 AC8B 314F B4CE 1171 4071 C7E1 D262 69C3 "Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment."
signature.asc
Description: PGP signature
_______________________________________________ Cloud mailing list -- [email protected] List information: https://lists.wikimedia.org/postorius/lists/cloud.lists.wikimedia.org/
