Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The test stream needs to be closed #1864

Merged
merged 1 commit into from Feb 15, 2024

Conversation

inverted-capital
Copy link
Contributor

@inverted-capital inverted-capital commented Feb 7, 2024

Otherwise resources are left dangling

@jcubic
Copy link
Contributor

jcubic commented Feb 7, 2024

Thanks for the PR. Unfortunately, this can't be merged because there are broken tests on master. Suddenly they stopped working and I don't know how to fix them.

@inverted-capital
Copy link
Contributor Author

inverted-capital commented Feb 7, 2024

I suspect that the tests are failing due to CompressionStream becoming available on android, and / or the implementation changing slightly. I have attempted to upgrade pako, whose issues repo mentions some compatibility issues that have been fixed. I will see how the pipeline tests go.

It comes down to the compression method in the utils/deflate.js file in isomorphic-git giving a different hash output on some platforms. I'm not entirely sure it matters, since the decompression algorithm will work fine either way, but it would be nice to have the same outputs on all platforms, just because its neater.

We should be prepared to let that constraint go if fixing this is too costly - we do not need binary output equivalence on all platforms to have functional output equivalence.

@jcubic
Copy link
Contributor

jcubic commented Feb 7, 2024

But the problem is that testing is always on the same platforms and suddenly it stops working. Nothing was updated. All PRs that were merged successfully passed all the tests.

@inverted-capital
Copy link
Contributor Author

I think what has happened is that the platforms that are used for the testing have updated something internally that changes how they do compression. I am poking around to try find out why.

@inverted-capital
Copy link
Contributor Author

Ok so I think that's the problem right there - CompressionStream on the Android platform must have changed recently, and it now produces something binarily different to what it did before. This may be because of how we're using it, but it might be a deeper bug.

We can either take the blunt fix I've put in here, or we can sniff if we are on the android platform and deny use of CompressionStream in that case until we know how to handle it better. Do you guys have a way to sniff Android in this codebase already ?

@jcubic
Copy link
Contributor

jcubic commented Feb 8, 2024

I don't like deleting the code like this, instead of figuring out what exactly is happening with the CompressStream on Android.

Also, the problem with deleting this code is that it has to work in the browser. I'm not sure if pako is included with the library for use inside the browser. That code was there for a reason.

@inverted-capital
Copy link
Contributor Author

Ok - I understand your reluctance to remove code like this.

pako definitely works in the browser, since all the tests that run in the browser use the deflate function. The reason for the CompressionStream code is given as performance, in the commit that made it

The tests were working 2 weeks ago, then something on android changed and now the tests are not working, even tho nothing changed here. That indicates something inside Android changed, and I don't have the ability to trace that deeper.

How about we just force pako only in Android, and then when Android changes back to match every other platform, we remove the conditional check ?

If we don't do this, then all PRs will be blocked until Android changes its behaviour back, or someone figures out what's going on there, which could be some time.

@inverted-capital
Copy link
Contributor Author

Ok so I've done a sniff for Android and the tests pass. The tests are running on Chrome 120 on Android 10 - this version of Chrome was released on Nov 28 - my best guest is there's a subtle discrepancy in there about the binary output of CompressionStream.

I cannot feasibly trace deeper than this.

@inverted-capital
Copy link
Contributor Author

The last PR to pass on Jan8 ran the android tests on chrome 117

@jcubic
Copy link
Contributor

jcubic commented Feb 11, 2024

I created an issue in the Chromium project. Let's see what they will say: https://issues.chromium.org/issues/324707366

I hope they will not close the issue as off-topic. I don't know any other way of contacting the developers of the Chromium project.

@inverted-capital
Copy link
Contributor Author

thank you 🙏 that is a good issue to raise with Chromium. Perhaps you could link them to the exact line of the log to look at, since they might not bother scrolling ? https://dev.azure.com/isomorphic-git/isomorphic-git/_build/results?buildId=3277&view=logs&j=0da5d1d9-276d-5173-c4c4-9d4d4ed14fdb&t=5b4cc83a-7bb0-5664-5bb1-588f7e4dc05b&l=16537

@jcubic
Copy link
Contributor

jcubic commented Feb 13, 2024

They replied that zlib library got updated. I'm not sure what the tests are doing but if they compare binary data output from the compression stream, those checks should be removed since the output can't change. It's not a fixed algorithm that will always output the same data.

@inverted-capital
Copy link
Contributor Author

I disagree with their opinion. This is the data format for zlib. I believe their implementation is out of spec, but I do not have the resources to say exactly why.

I believe maintaining binary compatibility should be upheld for isomorphic-git. We have working binary compatibility on Android provided by this PR, and my advice is to continue to treat Android as a special case until such time as their platform comes into compliance OR the other platforms move in the same way.

I am unsure if we have tests that compress on Android, push to Ubuntu, and decompress there. This type of usage might break if binary compatibility is abandoned.

The only loss from merging this PR is some performance degradation on Android.

@jcubic
Copy link
Contributor

jcubic commented Feb 14, 2024

I've sent an email to Zlib authors, let's see what they would say about this.

I would really not like to disable native compression just for Android only try to fix the unit tests.

@jcubic
Copy link
Contributor

jcubic commented Feb 14, 2024

I was able to fix the test and didn't compare any compressed blobs. The fixture is still binary pack file as before and the content of that pack file is read and compared with created pack file.

You can remove your check to ignore compressStream for Android and I will merge/squash all the changes. Make sure to rebase with the main branch.

@inverted-capital
Copy link
Contributor Author

Ok I will do that. I am concerned that with the changes you have made, there may be no testing path between creating a new pack file on Android with the out-of-spec native compression format, and opening that pack file on another platform.

Thank you for your persistence in tracing down this issue - much appreciated - this is a great library and very useful to me🙏

@jcubic
Copy link
Contributor

jcubic commented Feb 15, 2024

There is no way you can test that.

@jcubic jcubic merged commit 45bc531 into isomorphic-git:main Feb 15, 2024
4 checks passed
@isomorphic-git-bot
Copy link
Member

🎉 This PR is included in version 1.25.4 🎉

The release is available on:

Your semantic-release bot 📦🚀

modesty pushed a commit to modesty/isomorphic-git that referenced this pull request Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants