Comments (7)
Good to note, currently all of my packages have the same issue. So there is a chance it is not per module, but per user. As well as the chance of me doing something wrong, although I can't see how is that.
from lit.
After some thinking and talking to contributors, this might have been caused by a bad local litdb on my end. Just when I wanted to publish one of my packages, Lit reported an IO error related to my hard-disk -It is dying-
I am suspecting that what happened might have been:
- Bad local litdb that Lit only failed to read now.
- Lit server side does not do any validations of the data/hashes it is receiving.
- Lit managed to upload bad litdb to upstream all this time.
- I requested Tim to delete packages, and reuploaded, although that did not help. This might have been caused by the strong cache Lit do server side.
I am not sure if that is indeed the cause, but it is one possible scenario. Sadly, only way to test it out is by... deleting the packages and restarting the upstream server, and then trying to republish them. Sounds like too much trouble for a one user.
from lit.
I've been trying on a workaround of testing the previous theory, other than restarting the whole upstream since that's pretty problematic, and I came up with the idea of forcing a rehash on all malformed files then publishing that.
I tested that method on Bilal2453/vips and it seems indeed that was the issue, now it works after the workaround.
For anyone else who is having the same issue, here is a vague idea of how I did it:
- Patching Lit to not sync on publish. This is important since otherwise it will error before even trying to publish –which is indeed what I ran into before opening this issue, and didn't notice that because I had no idea what was the problem. Just comment this line out and re-build Lit.
- Edit all malformed files. Any edit to the contents will do. I simply added an empty comment at the top of each file, to force the rehash.
- Delete your .litdb.git. Do a backup of it if you wish, although that shouldn't matter.
- Use the patched Lit to re-publish your package, make sure you do bumb your versioning up.
After those steps my package seemed to behave itself.
@squeek502 Should we close this? Or perhaps suggest that Lit do account to a corrupted local litdb.git upstream and warn user about it. Another suggestion could be to add an option to force a publish without syncing, removing the need of a patch to local Lit, as an emergency way of escaping this loop.
I don't know if we should call this a bug, since it is basically Lit never checking the hashes it is receiving, so more of a missing feature perhaps?
from lit.
Seems like some sort of validation on either the client or server's end (or both?) would be nice. It's been a while since I've looked at the Lit internals though so I don't have any suggestions for what that might look like at the moment.
from lit.
Indeed, sounds like some missing validation, at the very least server side. I am honestly not quite sure where exactly either, I didn't dig to that point. But all I know is somewhere, the hash being used somehow mismatches in the git db (another theory was that the lit git implementation gets out of sync somehow).
And not being able to force a publish and/or somehow delete the package AND clear its cache server side adds to this issue, making user stuck in this loop of no hash errors.
from lit.
Oops that close was accidental
from lit.
Not sure what to say, but this is not as straightforward as I thought.
After publishing the problematic version, 1.1.10, I have published 1.1.11 of the mentioned package; and that version did behave just fine, until I published 1.1.12 that fixed some bugs in the previous one, both from a different new drive, and this time 1.1.12 had the same no hash problem.
This time with 3 files, and a binary. All of which have unique hashes not presented in any of the previous versions –intentionally to make sure no conflicts happen with the cache, yet it still got corrupted with different files this time.
I have as well spotted a pattern, each time I publish one of these "corrupted" modules... I get through this weird scenario after publishing the problematic version:
(In following example, I published a new version 1.1.13 to fix the second faulty one 1.1.12)
-
Publish is done with a new fresh litdb.git. Everything seems alright. (Not lit-bin used here is modified following the previously explained method)
-
Verifying the version was indeed published to lit through querying:
You notice here it is not the new one I just published.. what happened? You can verify that here too https://lit.luvit.io/packages/Bilal2453/vips/v1.1.13 . Let's ignore that and still try to install it. -
Trying to install the new version anyways, and we make sure that we delete .litdb.git before doing so:
We notice here it errors with a hash from v1.1.12, so it definitely is using older version.. but then we just published the new one.. -
Trying to re-publish (haven't done so yet) will tell you that said tag was already published and no new changes. But then querying lit, it says the latest version is indeed 1.1.13 and says that was uploaded a day ago (or whatever time it was on first publish).
It seems to always start this no hash problem after the previous pattern repeats. This has happened to me many times now and I only linked between it and between this bug now since I wasn't paying much attention to the no hash problem thinking it is a single user issue. I haven't yet done the last step I hope current state is easier to debug server side maybe.
Edit: I just did the last step of re-publishing and indeed got a new no hash problem even though I forced a rehash of almost everything
from lit.
Related Issues (20)
- New Lit version HOT 1
- Lit exe sometimes doesn't exit after it finishes HOT 1
- lit.luvit.io: 502 Bad Gateway errors HOT 3
- coro libraries naively assert coroutine resumes, original stack trace is lost. HOT 4
- coro-net/coro-http server leaks connections? HOT 17
- Mistaken Luvi and Lit versions in `get-lit.sh` on 3.8.5 branch? HOT 6
- Running lit commands in docker build segfault at exit. HOT 3
- Support managing development dependencies (?)
- When attempting to make packages from a GitHub repository, lit assumes the deprecated "master" branch HOT 1
- 'no start line' when running lit auth HOT 4
- coro-channel: resuming before having a chance to yield HOT 2
- An option for an HTTPS proxy
- lit publish `tag.type must be string` HOT 5
- Lit package archives are non-determininistic
- "unprotected error in call to Lua API" with custom binary HOT 5
- "unprotected error in call to Lua API" with custom binary HOT 1
- building lit with luajit-removed luvi causes build to fail HOT 5
- Mis-tagged release HOT 1
- Author name case sensitivity
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lit.