#Something seems to have messed up

1 messages · Page 1 of 1 (latest)

plucky burrow
#

any clue what?

errant shore
#

It's not a lot of tests having trouble. Don't you think it's an issue in those integrations? Or it's just not a lot of tests which snapshot this?

plucky burrow
#

Haven't checked. But I think I saw 3 failing with timezone stuff, so I wondered if it was something more widespread. Could have been coincidence

errant shore
#

Which is the third one? In the links it's chess.com and mastodon

#

FWIW I think it's the integrations doing something wrong + something changed in CI which exposes it.

#

Actually.

#

I think this is yet another case of tests influencing other tests.

#

Because it seems like it's very likely to happen again when CI is rerun.

errant shore
#

btw, for debugging these kind of issues, it would be extremely helpful if we could make pytest specify how many workers it starts in mode -n auto

#

It does say it in verbose mode "started 6 workers", but not in quiet mode which we use

errant shore
#

I'll check chess.com too. which was the third one?

#

chess.com also fails locally when running the full group

#

ugh, someone has modified the snapshot for mastodon so it fails locally but passes in CI 🤦‍♂️

#

bloody hell..

#

We're currently in the fun period where US is in DST but Europe is not. Maybe that's why this is now popping up?

plucky burrow
plucky burrow
errant shore
#

No, because like an idiot I ran tests and were happy that they were failing locally.

#

But they are failing locally because of two PRs which just hides the issue, so it passes in CI instead

#

I think the two offending integrations are using naïve timestamps somewhere, and with DST now being different in US vs EU that shows up

plucky burrow
errant shore
#

Yes, and now it's failing locally

#

The tests were updated to make them pass in CI

#

It's just hiding the issue

plucky burrow
#

ohhh they just updated the snapshots ? 🙃