2037822 - 0 byte test/ref images landed - Perma TEST-UNEXPECTED-PASS | /jpegxl/hdr-alpha-reftest.html when Gecko 152 merges to beta on 2026-05-18

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Sandor Molnar[:smolnar]]

Central as Beta simulation

How to run these simulations

Failure log

TEST-UNEXPECTED-PASS | /jpegxl/hdr-alpha-reftest.html | Testing http://web-platform.test:8000/jpegxl/hdr-alpha-reftest.html == http://web-platform.test:8000/jpegxl/hdr-alpha-reftest-ref.html

Comment 1

[Timothy Nikkel (:tnikkel)]

Ugh, the binary files got corrupted in the moz-phab lando process somewhere, I know there is an open bug about it.

Comment 2

[Timothy Nikkel (:tnikkel)]

Attachment: Bug 2037822. Re-add test/ref images that lando turned into 0-byte files due to a bug. r?#gfx-reviewers,saschanaz,#layout-reviewers

https://bugzilla.mozilla.org/show_bug.cgi?id=1709608 turned these new test files that I was adding in bug 2034984 into 0 byte files. Here are the original files.

Comment 3

[Timothy Nikkel (:tnikkel)]

I tried to land this patch and lando failed. This is what claude thinks is wrong:

The only place those files are non-empty is Lando's own server-side working clone. That clone
has drifted away from what Lando itself has pushed.

This actually fits the bug story neatly. The original "Lando turned them into 0 bytes" failure
was probably a serialization/transport bug in the push path: Lando applied a patch correctly to
its working tree (real bytes there), but emitted empty bytes when committing/pushing downstream.
So:

• Lando's working tree never lost the original real bytes
• hg autoland, git autoland, and the github mirror all received empty bytes
• Your re-add patch is based on the (correct) downstream view → empty
• It fails when applied to Lando's stale working tree → still has the originals

This is a Lando server-side bug; you can't fix it with a rebase. You need someone with Lando
admin access to resync /files/repos/firefox-autoland against upstream (or specifically git
checkout those four files from origin) so its working tree matches what was actually pushed.
Best path forward: ping the Conduit/Lando team in #conduit or #lando on Mozilla Slack, reference
landing job 44213, and explain that their autoland working clone has stale binary content for
those four files relative to both hg autoland and the github mirror.

Comment 4

[Timothy Nikkel (:tnikkel)]

This will go away in the next beta sim because of bug 2016688 (marking the test as passing in beta same as nightly), but the underlying problem of empty test/ref images still remains, so this bug should remain open to get that fixed.

Comment 5

[Timothy Nikkel (:tnikkel)]

ni to followup from matrix convo.

Comment 6

[Connor Sheehan [:sheehan]]

(In reply to Timothy Nikkel (:tnikkel) from comment #5)

ni to followup from matrix convo.

I believe you hit Bug 1865760. I have posted a PR and confirmed a fix for the underlying issue on the Phab-dev server, see Bug 1865760 comment 12 for more detail. We should have the PR deployed in the next day or so. Sorry for the inconvenience.

Comment 7

[Sandor Molnar[:smolnar]]

I can't apply locally the patch either, getting an error when I do so.

Comment 8

[Timothy Nikkel (:tnikkel)]

I just pulled mozilla central fresh and applied the patch, no issue.

What error are you seeing?

Comment 9

[Sandor Molnar[:smolnar]]

(In reply to Timothy Nikkel (:tnikkel) from comment #8)

I just pulled mozilla central fresh and applied the patch, no issue.

What error are you seeing?

Created branch phab-D299294_1
error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/sdr_alpha.png' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.
error: testing/web-platform/tests/jpegxl/resources/sdr_alpha.png: patch does not apply
error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/sdr_alpha.jxl' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.
error: testing/web-platform/tests/jpegxl/resources/sdr_alpha.jxl: patch does not apply
error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/hdr_alpha.png' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.
error: testing/web-platform/tests/jpegxl/resources/hdr_alpha.png: patch does not apply
error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/hdr_alpha.jxl' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.
error: testing/web-platform/tests/jpegxl/resources/hdr_alpha.jxl: patch does not apply

also my sheriff coleague tried it and he gets the same error.

Comment 10

[Timothy Nikkel (:tnikkel)]

error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/sdr_alpha.png' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.

e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 is the hash for an empty file. Is testing/web-platform/tests/jpegxl/resources/sdr_alpha.png an empty file in your tree?

Comment 11

[Sandor Molnar[:smolnar]]

(In reply to Timothy Nikkel (:tnikkel) from comment #10)

error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/sdr_alpha.png' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.

e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 is the hash for an empty file. Is testing/web-platform/tests/jpegxl/resources/sdr_alpha.png an empty file in your tree?

yes

Comment 12

[Timothy Nikkel (:tnikkel)]

Weird.
What happens if you delete the files and then try to apply the patch?

Comment 13

[Sandor Molnar[:smolnar]]

(In reply to Timothy Nikkel (:tnikkel) from comment #12)

Weird.
What happens if you delete the files and then try to apply the patch?

error: testing/web-platform/tests/jpegxl/resources/sdr_alpha.png: does not exist in index
error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/sdr_alpha.jxl' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.
error: testing/web-platform/tests/jpegxl/resources/sdr_alpha.jxl: patch does not apply
error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/hdr_alpha.png' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.
error: testing/web-platform/tests/jpegxl/resources/hdr_alpha.png: patch does not apply
error: the patch applies to 'testing/web-platform/tests/jpegxl/resources/hdr_alpha.jxl' (e69de29bb2d1d6434b8b29ae775ad8c2e48c5391), which does not match the current contents.
error: testing/web-platform/tests/jpegxl/resources/hdr_alpha.jxl: patch does not apply

I get a different error for that file

Comment 14

[Timothy Nikkel (:tnikkel)]

I'm not sure, maybe something in phab is mangling my patch after it leaves my system?

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Without --apply-to @:

Unknown revision: 0e22635834d4
CInnabar extension not enabled.
Use --apply-to to set the base commit.

--apply-to does expectedly not work around it.

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Timothy, could you share the whole stack, e.g. with moz-phab submit main:@ or share the fork anywhere?

Comment 17

[Timothy Nikkel (:tnikkel)]

There's no patch stack, it's just that one patch. It should apply to any recent commit.

Comment 18

[Timothy Nikkel (:tnikkel)]

Attachment: bug_2037822_re_add_test_ref_images_that_lando_turned_into_0_byte_files_due_

Here is the patch exported.

Comment 19

[Timothy Nikkel (:tnikkel)]

And I pushed it to try both with and without lando if that helps

https://treeherder.mozilla.org/jobs?repo=try&revision=cec521fdc0f0c3f74c3f54405f017c7253f18648

https://treeherder.mozilla.org/jobs?repo=try&revision=3395f6600281af094cbff4a8172963a3c68d252e

Comment 20

[Timothy Nikkel (:tnikkel)]

Attachment: claude's take

Comment 21

[Timothy Nikkel (:tnikkel)]

Attachment: 0001-Bug-XXXXXXX-Make-differential.getrawdiff-emit-valid-.patch

And this is what claude thinks is a fix for the bug.

The bug lies in the archived arcanist repo, so options for fixing it are awkward, this is what claude proposed.

Comment 22

[Connor Sheehan [:sheehan]]

Comment on attachment 9585916 [details] [diff] [review]
0001-Bug-XXXXXXX-Make-differential.getrawdiff-emit-valid-.patch

I've already fixed the Phabricator-side issue in bug 1865760.

Comment 23

[Timothy Nikkel (:tnikkel)]

My understanding was that bug 1865760 fixed the issue I ran into bug 2034984 where the binary files in my patches got turned into 0 byte files. In this bug I am facing a different issue: I am trying to land a patch that turns those 0 byte files already in the tree into non-zero byte files and the diff is not applying because the hash of the 0 byte files (the before) is being set to all zeroes, which is not the correct hash. Perhaps I have misunderstood.

Comment 24

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Will pushing this with the Lando API instead of the web client succeed? Because the merge is on Monday, it should land today.

Comment 25

[Timothy Nikkel (:tnikkel)]

(In reply to Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout) from comment #24)

Will pushing this with the Lando API instead of the web client succeed?

I don't know the answer to that question, feel free to try.

Because the merge is on Monday, it should land today.

See comment 4, this should be fixed in the beta sims, is it not?

(In reply to Timothy Nikkel (:tnikkel) from comment #4)

This will go away in the next beta sim because of bug 2016688 (marking the test as passing in beta same as nightly), but the underlying problem of empty test/ref images still remains, so this bug should remain open to get that fixed.

Comment 26

[agoloman]

Hi, it is green now. Should we leave this bug open?

Comment 27

[Timothy Nikkel (:tnikkel)]

Yes, this bug needs to stay open until those test/ref images are no longer 0 bytes. As they are testing nothing and we are losing jxl test coverage which I need in order to be confident of any changes I make the jxl's color handling (and I have some changes planned before enabling jxl).

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b9fa5375c410
https://hg.mozilla.org/integration/autoland/rev/27f637e1eded
Re-add test/ref images that lando turned into 0-byte files due to a bug. r=gfx-reviewers,layout-reviewers,emilio,bradwerth

Comment 29

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/84ba998dc7ce
https://hg.mozilla.org/releases/mozilla-beta/rev/318e79d2662a

Comment 30

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Failed to create upstream wpt PR due to merge conflicts. This requires fixup from a wpt sync admin.

Comment 31

[Timothy Nikkel (:tnikkel)]

Not sure why unrelated needinfo got cleared by the bot.

Comment 32

[Timothy Nikkel (:tnikkel)]

(In reply to Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org) from comment #30)

Failed to create upstream wpt PR due to merge conflicts. This requires fixup
from a wpt sync admin.

I looked at the wpt repo, it looks like the changes from bug 2034984 never made it to the wpt repo.

Comment 33

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/27f637e1eded

Comment 34

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/60014 for changes under testing/web-platform/tests

Comment 35

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 36

[Connor Sheehan [:sheehan]]

(In reply to Timothy Nikkel (:tnikkel) from comment #23)

My understanding was that bug 1865760 fixed the issue I ran into bug 2034984 where the binary files in my patches got turned into 0 byte files. In this bug I am facing a different issue: I am trying to land a patch that turns those 0 byte files already in the tree into non-zero byte files and the diff is not applying because the hash of the 0 byte files (the before) is being set to all zeroes, which is not the correct hash. Perhaps I have misunderstood.

Ah apologies, I misunderstood. Looking at comment 33 it seems we're okay now?

In case we aren't, the sheriffs should push a patch to git rm the file, and then we can land a patch (sheriffs or via Phab/Lando) that properly re-adds the file.

Sorry for the inconvenience, hopefully this is the last time anyone has to deal with this. :)

Comment 37

[Serban Stanca [:SerbanS]]

Verified fixed in today’s beta simulation push.