directory listing fails on the website

[nadako]

e.g. http://lib.haxe.org/p/hxnodejs/4.0.3/files/src

[ibilon]

Looks like it's only for newly uploaded versions http://lib.haxe.org/p/hxnodejs/4.0.2/files/ So most likely something from the last deploy.

[nadako]

Nah, it's the same http://lib.haxe.org/p/hxnodejs/4.0.2/files/src/

[ibilon]

Hmmm http://lib.haxe.org/p/lime/2.9.0/files/lime/tools/mpeg/audio/ this works And this too http://lib.haxe.org/p/hxnodejs/4.0.2/files/haxelib.json

[ibilon]

This doesn't work http://lib.haxe.org/p/haxelib_client/3.2.0-rc.3/files/src/

So I guess src folders aren't working.

[nadako]

that's really weird

[ibilon]

Seems random http://lib.haxe.org/p/openfl-samples/3.1.0/files/openfl-samples/ http://lib.haxe.org/p/openfl-samples/3.3.1/files/openfl-samples/ maybe some decompression/file creation issue?

[nadako]

Hmm, I think it's deployed, but the problem is still there. I wonder why it worked for me locally.

[nadako]

It works for new uploads (http://lib.haxe.org/p/hxnodejs/4.0.4/files/src), so this is probably a cache issue.

[ibilon]

That's still a strange bug even if the cache is behaving weirdly

That's only on directory http://lib.haxe.org/p/openfl-samples/3.3.1/files/openfl-samples/ http://lib.haxe.org/p/openfl-samples/3.3.1/files/openfl-samples/README.md you can access the files if you know about them and not all directories of the same lib version fail http://lib.haxe.org/p/openfl-samples/3.3.1/files/openfl-samples/demos/NyanCat/

[nadako]

@andyli or @jasononeil (still not sure who to ping) this might require some server maintainance: we need to clear zip caches.

I see this ufront task that should do that, but it requires project/version, and I think we need to do that for ALL projects and versions: https://github.com/HaxeFoundation/haxelib/blob/development/src/website/tasks/HaxelibCacheTasks.hx#L21

[nadako]

@ibilon I think I fixed that, see e7e6b615f937c3dc888bf2bf0164288ad8444b8e

[nadako]

I.e. that depends on whether entry was added to the zip file for a directory or not.

[ibilon]

Oh I see, make sense.

[ibilon]

I see this ufront task that should do that, but it requires project/version, and I think we need to do that for ALL projects and versions

There's always clearAll https://github.com/HaxeFoundation/haxelib/blob/development/src/website/tasks/HaxelibCacheTasks.hx#L15 it's a bit overkill but at least it'd work.

[nadako]

I was toying with tasks.n today and couldn't get it to work - it seems that there's something wrong with minject or injector configuration, so HaxelibCacheTasks.api doesn't get set to a DBCacheApi instance and it crashes.

Could someone with ufront/minject knowledge help me here?

[ibilon]

I looked at this, it does the injection but with the value null. most likely since injector.getInstance(DBCacheApi) throws Uncaught exception - Error while getting mapping response: No mapping defined for class "ufront.cache.DBCacheApi" name "null"

But the class is correctly returned in this https://github.com/HaxeFoundation/haxelib/blob/development/src/website/Tasks.hx#L34

Still fails even if I add tasks.injector.map( DBCacheApi ).toClass( DBCacheApi );

Well anyway, I get the use of injection, but here it's a 100 lines software that's not meant to be used as a library where we do obj.fn(), removing the injection and doing new DBCacheApi().clearAll(); would be so much simpler.

[markknol]

Any news on how we could resolve this?