Can't download archive over https

fricklerhandwerk commented

2025-07-15 08:41:25 +02:00

Owner

I want to enable consumers with a vanilla Nix installation such as after

apt install --yes curl git jq nix

to run some tests to validate that our software works as advertised, e.g.

nix-build https://git.fediversity.eu/Fediversity/Fediversity/archive/main.tar.gz -A tests

This doesn't work because the archive URL times out.

url -v https://git.fediversity.eu/Fediversity/Fediversity/archive/main.zip
* Host git.fediversity.eu:443 was resolved.
* IPv6: 2a00:51c0:12:1201::20
* IPv4: 185.206.232.34
*   Trying [2a00:51c0:12:1201::20]:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=git.fediversity.eu
*  start date: Jul 13 23:28:25 2025 GMT
*  expire date: Oct 11 23:28:24 2025 GMT
*  subjectAltName: host "git.fediversity.eu" matched cert's "git.fediversity.eu"
*  issuer: C=US; O=Let's Encrypt; CN=E6
*  SSL certificate verify ok.
*   Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
* Connected to git.fediversity.eu (2a00:51c0:12:1201::20) port 443
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://git.fediversity.eu/Fediversity/Fediversity/archive/main.zip
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: git.fediversity.eu]
* [HTTP/2] [1] [:path: /Fediversity/Fediversity/archive/main.zip]
* [HTTP/2] [1] [user-agent: curl/8.11.0]
* [HTTP/2] [1] [accept: */*]
> GET /Fediversity/Fediversity/archive/main.zip HTTP/2
> Host: git.fediversity.eu
> User-Agent: curl/8.11.0
> Accept: */*
> 
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
^C⏎

I want to enable consumers with a vanilla Nix installation such as after ```bash apt install --yes curl git jq nix ``` to run some tests to validate that our software works as advertised, e.g. ```bash nix-build https://git.fediversity.eu/Fediversity/Fediversity/archive/main.tar.gz -A tests ``` This doesn't work because the `archive` URL times out. <details> ```log url -v https://git.fediversity.eu/Fediversity/Fediversity/archive/main.zip * Host git.fediversity.eu:443 was resolved. * IPv6: 2a00:51c0:12:1201::20 * IPv4: 185.206.232.34 * Trying [2a00:51c0:12:1201::20]:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / id-ecPublicKey * ALPN: server accepted h2 * Server certificate: * subject: CN=git.fediversity.eu * start date: Jul 13 23:28:25 2025 GMT * expire date: Oct 11 23:28:24 2025 GMT * subjectAltName: host "git.fediversity.eu" matched cert's "git.fediversity.eu" * issuer: C=US; O=Let's Encrypt; CN=E6 * SSL certificate verify ok. * Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using ecdsa-with-SHA384 * Certificate level 1: Public key type EC/secp384r1 (384/192 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption * Connected to git.fediversity.eu (2a00:51c0:12:1201::20) port 443 * using HTTP/2 * [HTTP/2] [1] OPENED stream for https://git.fediversity.eu/Fediversity/Fediversity/archive/main.zip * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: git.fediversity.eu] * [HTTP/2] [1] [:path: /Fediversity/Fediversity/archive/main.zip] * [HTTP/2] [1] [user-agent: curl/8.11.0] * [HTTP/2] [1] [accept: */*] > GET /Fediversity/Fediversity/archive/main.zip HTTP/2 > Host: git.fediversity.eu > User-Agent: curl/8.11.0 > Accept: */* > * Request completely sent off * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): ^C⏎ ```

fricklerhandwerk added the

user experience

bug

labels 2025-07-15 08:41:25 +02:00

kiara commented

2025-07-15 11:37:42 +02:00

Owner

forgejo seems to respond HTTP 504 for both tarball and zip.
the forgejo server's logs /var/log/nginx/{access,error}.log did not mention these requests unfortunately.

to be fair, we could update the forgejo, altho for all i know this could relate to the nginx as well?

forgejo seems to respond HTTP 504 for both tarball and zip. the forgejo server's logs `/var/log/nginx/{access,error}.log` did not mention these requests unfortunately. to be fair, we could update the forgejo, altho for all i know this could relate to the nginx as well?

kiara commented

2025-08-21 10:13:29 +02:00

Owner

this is also currently blocking us from sourcing dependencies from our forgejo (using npins), e.g. vars / nix-templating

this is also currently blocking us from sourcing dependencies from our forgejo (using npins), e.g. [`vars`](https://git.fediversity.eu/Fediversity/vars) / [`nix-templating`](https://git.fediversity.eu/Fediversity/nix-templating)

kiara commented

2025-10-28 15:09:32 +01:00

Owner

should probably recheck the nginx settings for time-out values, which now seems to be set to one minute, corresponding to defaults for services.nginx.proxyTimeout and services.nginx.uwsgiTimeout.

should probably recheck the nginx settings for time-out values, which now seems to be set to one minute, corresponding to defaults for `services.nginx.proxyTimeout` and `services.nginx.uwsgiTimeout`.

kiara commented

2025-10-28 16:10:18 +01:00

Owner

increasing this to 15m (for both) seems to not yet fix this somehow:

$ curl -vvv https://git.fediversity.eu/Fediversity/Fediversity/archive/main.zip
...
15:52:04.972941 [0-0] == Info: [HTTP/2] [1] <- FRAME[HEADERS, len=49, hend=1, eos=0]
15:52:04.973256 [0-0] <= Recv header, 2 bytes (0x2)
0000:
15:52:04.973413 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=2) -> 0
15:52:04.973607 [0-0] == Info: [WRITE] [OUT] wrote 2 header bytes -> 2
15:52:04.973813 [0-0] == Info: [WRITE] [PAUSE] writing 2/2 bytes of type 4 -> 0
15:52:04.974008 [0-0] == Info: [WRITE] download_write header(type=4, blen=2) -> 0
15:52:04.974215 [0-0] == Info: [WRITE] client_write(type=4, len=2) -> 0
15:52:04.974380 [0-0] <= Recv data, 160 bytes (0xa0)
0000: <html>
0008: <head><title>504 Gateway Time-out</title></head>
003a: <body>
0042: <center><h1>504 Gateway Time-out</h1></center>
0072: <hr><center>nginx</center>
008e: </body>
0097: </html>
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>
15:52:04.975321 [0-0] == Info: [WRITE] [OUT] wrote 160 body bytes -> 160
15:52:04.975477 [0-0] == Info: [WRITE] [PAUSE] writing 160/160 bytes of type 1 -> 0
15:52:04.975667 [0-0] == Info: [WRITE] download_write body(type=1, blen=160) -> 0
15:52:04.975859 [0-0] == Info: [WRITE] client_write(type=1, len=160) -> 0
15:52:04.976019 [0-0] == Info: [WRITE] xfer_write_resp(len=160, eos=0) -> 0
15:52:04.976200 [0-0] == Info: [HTTP/2] [1] <- FRAME[DATA, len=160, eos=1, padlen=0]
15:52:04.976395 [0-0] == Info: [HTTP/2] [1] DATA, window=160/20905984
15:52:04.976546 [0-0] == Info: [HTTP/2] [1] CLOSED
15:52:04.976749 [0-0] == Info: [HTTP/2] [0] progress ingress: inbufg=0
15:52:04.976923 [0-0] == Info: [HTTP/2] [0] progress ingress: done
15:52:04.977107 [0-0] == Info: [HTTP/2] [1] returning CLOSE
15:52:04.977233 [0-0] == Info: [HTTP/2] handle_stream_close -> 0, 0
15:52:04.977468 [0-0] == Info: [HTTP/2] [1] cf_recv(len=102400) -> 0, 0, window=-1/-1, connection 1048575840/1048576000
15:52:04.977710 [0-0] <= Recv data, 0 bytes (0x0)
15:52:04.977811 [0-0] == Info: [WRITE] [PAUSE] writing 0/0 bytes of type 81 -> 0
15:52:04.977995 [0-0] == Info: [WRITE] download_write body(type=81, blen=0) -> 0
15:52:04.978155 [0-0] == Info: [WRITE] client_write(type=81, len=0) -> 0
15:52:04.978290 [0-0] == Info: [WRITE] xfer_write_resp(len=0, eos=1) -> 0
15:52:04.978443 [0-0] == Info: [WRITE] [OUT] done
15:52:04.978534 [0-0] == Info: [READ] client_reset, clear readers
15:52:04.978955 [0-0] == Info: Connection #0 to host git.fediversity.eu:443 left intact

increasing this to `15m` ([for both](https://git.fediversity.eu/fediversity/fediversity/compare/main...kiara:forgejo-timeout)) seems to not yet fix this somehow: ``` $ curl -vvv https://git.fediversity.eu/Fediversity/Fediversity/archive/main.zip ... 15:52:04.972941 [0-0] == Info: [HTTP/2] [1] <- FRAME[HEADERS, len=49, hend=1, eos=0] 15:52:04.973256 [0-0] <= Recv header, 2 bytes (0x2) 0000: 15:52:04.973413 [0-0] == Info: [WRITE] header_collect pushed(type=1, len=2) -> 0 15:52:04.973607 [0-0] == Info: [WRITE] [OUT] wrote 2 header bytes -> 2 15:52:04.973813 [0-0] == Info: [WRITE] [PAUSE] writing 2/2 bytes of type 4 -> 0 15:52:04.974008 [0-0] == Info: [WRITE] download_write header(type=4, blen=2) -> 0 15:52:04.974215 [0-0] == Info: [WRITE] client_write(type=4, len=2) -> 0 15:52:04.974380 [0-0] <= Recv data, 160 bytes (0xa0) 0000: <html> 0008: <head><title>504 Gateway Time-out</title></head> 003a: <body> 0042: <center><h1>504 Gateway Time-out</h1></center> 0072: <hr><center>nginx</center> 008e: </body> 0097: </html> <html> <head><title>504 Gateway Time-out</title></head> <body> <center><h1>504 Gateway Time-out</h1></center> <hr><center>nginx</center> </body> </html> 15:52:04.975321 [0-0] == Info: [WRITE] [OUT] wrote 160 body bytes -> 160 15:52:04.975477 [0-0] == Info: [WRITE] [PAUSE] writing 160/160 bytes of type 1 -> 0 15:52:04.975667 [0-0] == Info: [WRITE] download_write body(type=1, blen=160) -> 0 15:52:04.975859 [0-0] == Info: [WRITE] client_write(type=1, len=160) -> 0 15:52:04.976019 [0-0] == Info: [WRITE] xfer_write_resp(len=160, eos=0) -> 0 15:52:04.976200 [0-0] == Info: [HTTP/2] [1] <- FRAME[DATA, len=160, eos=1, padlen=0] 15:52:04.976395 [0-0] == Info: [HTTP/2] [1] DATA, window=160/20905984 15:52:04.976546 [0-0] == Info: [HTTP/2] [1] CLOSED 15:52:04.976749 [0-0] == Info: [HTTP/2] [0] progress ingress: inbufg=0 15:52:04.976923 [0-0] == Info: [HTTP/2] [0] progress ingress: done 15:52:04.977107 [0-0] == Info: [HTTP/2] [1] returning CLOSE 15:52:04.977233 [0-0] == Info: [HTTP/2] handle_stream_close -> 0, 0 15:52:04.977468 [0-0] == Info: [HTTP/2] [1] cf_recv(len=102400) -> 0, 0, window=-1/-1, connection 1048575840/1048576000 15:52:04.977710 [0-0] <= Recv data, 0 bytes (0x0) 15:52:04.977811 [0-0] == Info: [WRITE] [PAUSE] writing 0/0 bytes of type 81 -> 0 15:52:04.977995 [0-0] == Info: [WRITE] download_write body(type=81, blen=0) -> 0 15:52:04.978155 [0-0] == Info: [WRITE] client_write(type=81, len=0) -> 0 15:52:04.978290 [0-0] == Info: [WRITE] xfer_write_resp(len=0, eos=1) -> 0 15:52:04.978443 [0-0] == Info: [WRITE] [OUT] done 15:52:04.978534 [0-0] == Info: [READ] client_reset, clear readers 15:52:04.978955 [0-0] == Info: Connection #0 to host git.fediversity.eu:443 left intact ```

kiara commented

2025-10-28 22:09:09 +01:00

Owner

https://git.fediversity.eu/admin/monitor/queue shows queue repo-archive dysfunctional, with a massive number of hanging items, apparently systematically failing to get processed.

the following interaction feels suspicious:

[nix-shell:~]$ sudo -u forgejo bash

[forgejo@vm02116:/home/kiara]$ cd /var/lib/forgejo/repositories/fediversity/nix-templating.git

[forgejo@vm02116:~/repositories/fediversity/nix-templating.git]$ git archive --format=tar.gz HEAD -o /tmp/test-direct.tar.gz
The program 'git' is not in your PATH. It is provided by several packages.
You can make it available in an ephemeral shell by typing one of the following:
  nix-shell -p git
  nix-shell -p git-doc
  nix-shell -p gitMinimal
  nix-shell -p gitSVN

[forgejo@vm02116:/home/kiara]$ git --version
git version 2.48.1

edit: ensuring package availability at machines/dev/vm02116/forgejo.nix appears not to have fixed this yet:

  environment.systemPackages = [
    pkgs.git
  ];

  users.users.forgejo = {
    packages = [
      pkgs.git
    ];
  };

https://git.fediversity.eu/admin/monitor/queue shows queue `repo-archive` dysfunctional, with a massive number of hanging items, apparently systematically failing to get processed. the following interaction feels suspicious: ``` [nix-shell:~]$ sudo -u forgejo bash [forgejo@vm02116:/home/kiara]$ cd /var/lib/forgejo/repositories/fediversity/nix-templating.git [forgejo@vm02116:~/repositories/fediversity/nix-templating.git]$ git archive --format=tar.gz HEAD -o /tmp/test-direct.tar.gz The program 'git' is not in your PATH. It is provided by several packages. You can make it available in an ephemeral shell by typing one of the following: nix-shell -p git nix-shell -p git-doc nix-shell -p gitMinimal nix-shell -p gitSVN [forgejo@vm02116:/home/kiara]$ git --version git version 2.48.1 ``` edit: ensuring package availability at `machines/dev/vm02116/forgejo.nix` appears not to have fixed this yet: ```nix environment.systemPackages = [ pkgs.git ]; users.users.forgejo = { packages = [ pkgs.git ]; }; ```

kiara commented

2025-10-29 20:02:30 +01:00

Owner

so far i'm not finding issues mentioning that particular queue at forgejo's issue tracker.
i'm trying to figure out how to investigate processing of this queue, whether in code or by inspecting this leveldb that our forgejo seems configured to use (which seems used in-process).

so far i'm not finding issues mentioning that particular queue at forgejo's issue tracker. i'm trying to figure out how to investigate processing of this queue, whether in code or by inspecting this leveldb that our forgejo seems configured to use (which seems used in-process).

kiara commented

2025-10-29 20:44:16 +01:00

Owner

gitea has setting queue.*.WORKERS (default 0), while forgejo only documents MAX_WORKERS (default cpus/2). to be fair, i cannot find even MAX_WORKERS defined in forgejo's code, so perhaps these all just inherited from levelqueue, implying WORKERS might work for forgejo as well.

so far tho, following grouping with ., either of:

services.forgejo.settings."queue.repo-archive".WORKERS = 1;
services.forgejo.settings."queue.repo-archive".WORKERS = 1;

.. while showing up in the forgejo config file, seem not to get reflected in the number of workers (which to be fair is listed at 0 for each queue now, while others tend to have functioned fine).

actual processing logic seems defined at doArchive, tho i've yet to figure out how to use the info there to find a next step to try.

gitea has setting `queue.*.WORKERS` (default `0`), while forgejo only documents `MAX_WORKERS` (default cpus/2). to be fair, i cannot find even `MAX_WORKERS` defined in forgejo's code, so perhaps these all just inherited from levelqueue, implying `WORKERS` might work for forgejo as well. so far tho, following [grouping with `.`](https://search.nixos.org/options?channel=unstable&show=services.forgejo.settings&query=services.forgejo), either of: - `services.forgejo.settings."queue.repo-archive".WORKERS = 1;` - `services.forgejo.settings."queue.repo-archive".WORKERS = 1;` .. while showing up in the forgejo config file, seem not to get reflected in the [number of workers](https://git.fediversity.eu/admin/monitor/queue) (which to be fair is listed at 0 for each queue now, while others tend to have functioned fine). actual processing logic seems defined at [`doArchive`](https://codeberg.org/forgejo/forgejo/src/commit/15a2d300d79ac717f3e05b239eb0759f808889a1/services/repository/archiver/archiver.go#L183), tho i've yet to figure out how to use the info there to find a next step to try.

kiara commented

2025-10-29 21:29:54 +01:00

Owner

from an strace log, archiving jobs are getting pkilled by forgejo:

2034770 chdir("/var/lib/forgejo/repositories/fricklerhandwerk/meta.git") = 0
2034770 execve("/nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git", ["/nix/store/lqx2rv26sdndpa2vyy2vx"..., "-c", "protocol.version=2", "-c", "credential.helper=", "-c", "filter.lfs.required=", "-c", "filter.lfs.smudge=", "-c", "filter.lfs.clean=", "cat-file", "--batch"], 0xc002ec3b00 /* 31 vars */ <unfinished ...>
...
2030404 pidfd_send_signal(46, SIGKILL, NULL, 0) = 0
2034770 +++ killed by SIGKILL +++

an attempt to clear the queues:

# sudo su - forgejo
$ /nix/store/3n03wrkqjvr2z8z25vj77ydn1hkzm2az-forgejo-10.0.3/bin/gitea manager flush-queues -w /var/lib/forgejo --non-blocking --timeout 5m
Flushed
$ /nix/store/3n03wrkqjvr2z8z25vj77ydn1hkzm2az-forgejo-10.0.3/bin/gitea manager flush-queues -w /var/lib/forgejo --debug
 --debug
2025/10/29 22:13:02 ...dules/git/command.go:301:Run() [D] git.Command.Run: /nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git version
2025/10/29 22:13:02 ...s/process/manager.go:188:Add() [T] Start 6902835e-7: git: /nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git version (normal)
2025/10/29 22:13:02 ...s/process/manager.go:231:remove() [T] Done 6902835e-7: git: /nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git version
context deadline exceeded
internal API error response, status=408

.. so far seems not to have affected the current count.
is the queue so big that flushing just times out?

unfortunately, neither leveldb nor levelqueue seem to offer their own CLIs.

nor does services.forgejo.settings.queue.LENGTH = 100; get rid of superfluous jobs.

now, queue contents seem tied to services.forgejo.settings.queue.TYPE, meaning switching this temporarily can resolve the symptoms:

level ^
channel - switching to this made all queues display 0 outstanding items, and new download requests seem to go through! 🎉
redis

from an `strace` log, archiving jobs are getting `pkill`ed by forgejo: ``` 2034770 chdir("/var/lib/forgejo/repositories/fricklerhandwerk/meta.git") = 0 2034770 execve("/nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git", ["/nix/store/lqx2rv26sdndpa2vyy2vx"..., "-c", "protocol.version=2", "-c", "credential.helper=", "-c", "filter.lfs.required=", "-c", "filter.lfs.smudge=", "-c", "filter.lfs.clean=", "cat-file", "--batch"], 0xc002ec3b00 /* 31 vars */ <unfinished ...> ... 2030404 pidfd_send_signal(46, SIGKILL, NULL, 0) = 0 2034770 +++ killed by SIGKILL +++ ``` an attempt to clear the queues: ```bash # sudo su - forgejo $ /nix/store/3n03wrkqjvr2z8z25vj77ydn1hkzm2az-forgejo-10.0.3/bin/gitea manager flush-queues -w /var/lib/forgejo --non-blocking --timeout 5m Flushed $ /nix/store/3n03wrkqjvr2z8z25vj77ydn1hkzm2az-forgejo-10.0.3/bin/gitea manager flush-queues -w /var/lib/forgejo --debug --debug 2025/10/29 22:13:02 ...dules/git/command.go:301:Run() [D] git.Command.Run: /nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git version 2025/10/29 22:13:02 ...s/process/manager.go:188:Add() [T] Start 6902835e-7: git: /nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git version (normal) 2025/10/29 22:13:02 ...s/process/manager.go:231:remove() [T] Done 6902835e-7: git: /nix/store/lqx2rv26sdndpa2vyy2vxsahj03km69z-git-2.48.1/bin/git version context deadline exceeded internal API error response, status=408 ``` .. so far seems not to have affected the [current count](https://git.fediversity.eu/admin/monitor/queue). is the queue so big that flushing just times out? unfortunately, neither `leveldb` nor `levelqueue` seem to offer their own CLIs. nor does `services.forgejo.settings.queue.LENGTH = 100;` get rid of superfluous jobs. now, queue contents seem tied to `services.forgejo.settings.queue.TYPE`, meaning switching this temporarily can resolve the symptoms: - `level` ^ - `channel` - switching to this made all queues display `0` outstanding items, and new download requests seem to go through! :tada: - `redis`

kiara closed this issue

2025-10-29 22:48:05 +01:00

kiara referenced this issue

2025-10-29 22:54:34 +01:00

for forgejo use queue type channel #559

kiara referenced this issue from a commit

2025-10-29 22:55:08 +01:00

for forgejo use queue type `channel` (#559)

kiara referenced this issue

2025-10-29 23:05:50 +01:00

in-source patches #560

kiara commented

2025-10-30 12:30:11 +01:00

Owner

to get rid of the work-around, i may wanna look into clearing the leveldb queue:

[nix-shell:~]$ sudo ls -la /var/lib/forgejo/data/queues
total 16
drwxr-x---  4 forgejo forgejo 4096 Oct 28 22:29 .
drwxr-x--- 16 forgejo forgejo 4096 Nov 26  2024 ..
drwxr-x---  2 forgejo forgejo 4096 Oct 29 22:52 common
drwxr-xr-x  2 forgejo forgejo 4096 Oct 28 22:29 repo-archive

[nix-shell:~]$ sudo ls -la /var/lib/forgejo/data/queues/common
total 4068
drwxr-x--- 2 forgejo forgejo    4096 Oct 29 22:52 .
drwxr-x--- 4 forgejo forgejo    4096 Oct 28 22:29 ..
-rw-r----- 1 forgejo forgejo 1955337 Oct 29 22:38 000223.ldb
-rw-r----- 1 forgejo forgejo    1877 Oct 29 22:53 000225.log
-rw-r----- 1 forgejo forgejo 2117896 Oct 29 22:52 000227.ldb
-rw-r----- 1 forgejo forgejo      16 Oct 29 22:49 CURRENT
-rw-r----- 1 forgejo forgejo      16 Oct 29 22:49 CURRENT.bak
-rw-r----- 1 forgejo forgejo       0 Jan 30  2024 LOCK
-rw-r----- 1 forgejo forgejo   56885 Oct 29 22:52 LOG
-rw-r----- 1 forgejo forgejo     736 Oct 29 22:52 MANIFEST-000226

[nix-shell:~]$ sudo ls -la /var/lib/forgejo/data/queues/repo-archive
total 8
drwxr-xr-x 2 forgejo forgejo 4096 Oct 28 22:29 .
drwxr-x--- 4 forgejo forgejo 4096 Oct 28 22:29 ..

let's see if i could just (re)move it to clear.

to get rid of the work-around, i may wanna look into clearing the leveldb queue: ``` [nix-shell:~]$ sudo ls -la /var/lib/forgejo/data/queues total 16 drwxr-x--- 4 forgejo forgejo 4096 Oct 28 22:29 . drwxr-x--- 16 forgejo forgejo 4096 Nov 26 2024 .. drwxr-x--- 2 forgejo forgejo 4096 Oct 29 22:52 common drwxr-xr-x 2 forgejo forgejo 4096 Oct 28 22:29 repo-archive [nix-shell:~]$ sudo ls -la /var/lib/forgejo/data/queues/common total 4068 drwxr-x--- 2 forgejo forgejo 4096 Oct 29 22:52 . drwxr-x--- 4 forgejo forgejo 4096 Oct 28 22:29 .. -rw-r----- 1 forgejo forgejo 1955337 Oct 29 22:38 000223.ldb -rw-r----- 1 forgejo forgejo 1877 Oct 29 22:53 000225.log -rw-r----- 1 forgejo forgejo 2117896 Oct 29 22:52 000227.ldb -rw-r----- 1 forgejo forgejo 16 Oct 29 22:49 CURRENT -rw-r----- 1 forgejo forgejo 16 Oct 29 22:49 CURRENT.bak -rw-r----- 1 forgejo forgejo 0 Jan 30 2024 LOCK -rw-r----- 1 forgejo forgejo 56885 Oct 29 22:52 LOG -rw-r----- 1 forgejo forgejo 736 Oct 29 22:52 MANIFEST-000226 [nix-shell:~]$ sudo ls -la /var/lib/forgejo/data/queues/repo-archive total 8 drwxr-xr-x 2 forgejo forgejo 4096 Oct 28 22:29 . drwxr-x--- 4 forgejo forgejo 4096 Oct 28 22:29 .. ``` let's see if i could just (re)move it to clear.

kiara reopened this issue

2025-10-30 12:30:18 +01:00

kiara referenced this issue from a pull request that will close it,

2025-10-30 13:08:57 +01:00

Revert "for forgejo use queue type channel (#559)" #562

kiara commented

2025-10-30 13:09:37 +01:00

Owner

that seems to have done it, so opened #562 now that this seems fixed (for now?).

kiara referenced this issue from a commit

2025-10-30 13:09:49 +01:00

Revert "for forgejo use queue type `channel` (#559)" (#562)