AkkomaGang/akkoma
AkkomaGang/akkoma
17
70
Fork 112
Code Issues 152 Pull requests 23 Projects 2 Releases 21 Packages Wiki Activity

Cannot fetch from IPv6-only instance with CNAME entry #947

New issue
Open
opened 2025-07-11 16:28:12 +00:00 by Oneric · 3 comments
Oneric commented 2025-07-11 16:28:12 +00:00
Owner
Copy link

Your setup

From source

Extra details

Alpine 3.22

Version

3.15.2-wf-100-gd3da49f2-u16d7d612f-trunk (i.e. basically 16d7d612f)

PostgreSQL version

17

What’s wrong?

Fetches from an IPv6-only instance whose domain is a CNAME entry fail with :nxdomain (frequently showing up in logs), fetches from IPv6-only instances without a CNAME entry succeed since #708.

The odd thing is, manually Finch and Mint there’s no issue with connecting to the instance providing inet6: true is set in transport_opts (which we set by default). Not even manual Tesla.get calls fail when providing a simple client using the Finch adapter and our existing Finch pool.
However, using Tesla.get without providing this simple test client; this should whatever default was specified in the config — but our config provides an identical client setup(!):

# config/config.exs
config :tesla, :adapter, {Tesla.Adapter.Finch, name: MyFinch}

# remote shell of running instance
iex(1)> client = Tesla.client([], {Tesla.Adapter.Finch, name: MyFinch})
iex(2)> Tesla.get(client, "https://gts.wezen.famfo.xyz/")
# works
iex(3)> Tesla.get("https://gts.wezen.famfo.xyz/")                                                      
{:error, :nxdomain}

Not sure if somethings wrong with our Tesla setup or if it’s a Tesla bug

Test instance (just grabbing what showed up in logs):

  • ipv6.camp: IPv6-only, no CNAME
  • gts.wezen.famfo.xyz: CNAME domain; IPv6-only

Severity

I can manage

Have you searched for this issue?

  • I have double-checked and have not found this issue mentioned anywhere.
### Your setup From source ### Extra details Alpine 3.22 ### Version 3.15.2-wf-100-gd3da49f2-u16d7d612f-trunk (i.e. basically 16d7d612f) ### PostgreSQL version 17 ### What’s wrong? Fetches from an IPv6-only instance whose domain is a CNAME entry fail with `:nxdomain` (frequently showing up in logs), fetches from IPv6-only instances without a CNAME entry succeed since #708. The odd thing is, manually Finch and Mint there’s no issue with connecting to the instance providing `inet6: true` is set in `transport_opts` *(which we set by default)*. Not even manual `Tesla.get` calls fail when providing a simple client using the Finch adapter and our existing Finch pool. However, using `Tesla.get` _without_ providing this simple test client; this should whatever default was specified in the config — but our config provides an identical client setup(!): ```elixir # config/config.exs config :tesla, :adapter, {Tesla.Adapter.Finch, name: MyFinch} # remote shell of running instance iex(1)> client = Tesla.client([], {Tesla.Adapter.Finch, name: MyFinch}) iex(2)> Tesla.get(client, "https://gts.wezen.famfo.xyz/") # works iex(3)> Tesla.get("https://gts.wezen.famfo.xyz/") {:error, :nxdomain} ``` Not sure if somethings wrong with our Tesla setup or if it’s a Tesla bug Test instance *(just grabbing what showed up in logs)*: - `ipv6.camp`: IPv6-only, no CNAME - `gts.wezen.famfo.xyz`: CNAME domain; IPv6-only ### Severity I can manage ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.
floatingghost commented 2025-07-11 16:57:26 +00:00
Owner
Copy link

we're a bit out of date with tesla/finch deps - you could potentially try bumping those?

i'm trying to test it but my ISP doesn't provide ipv6

we're a bit out of date with tesla/finch deps - you could potentially try bumping those? i'm trying to test it but my ISP doesn't provide ipv6
Oneric commented 2025-07-11 23:03:54 +00:00
Author
Owner
Copy link

It gets weirder: it actually works on my local machine in both dev and prod env, but not on the actual prod instance from which the above report was generated. Erlang, Elixir, etc versions are equivalent (both use Aloine 3.22 packages). DNS responses also look similar.
The only difference is the local machine being x86_64 and the prod instance aarch64, but this shouldn’t matter for DNS resolution.

DNS responses on prod instance 
$ dig gts.wezen.famfo.xyz A
; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53430
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gts.wezen.famfo.xyz.           IN      A

;; ANSWER SECTION:
gts.wezen.famfo.xyz.    3597    IN      CNAME   wezen.canis-major.famfo.xyz.

;; AUTHORITY SECTION:
famfo.xyz.              3597    IN      SOA     ns1.famfo.xyz. dns.famfo.xyz. 2025108060 10800 3600 604800 3600

;; Query time: 0 msec
;; MSG SIZE  rcvd: 124



$ dig gts.wezen.famfo.xyz AAAA
; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39796
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gts.wezen.famfo.xyz.           IN      AAAA

;; ANSWER SECTION:
gts.wezen.famfo.xyz.    3250    IN      CNAME   wezen.canis-major.famfo.xyz.
wezen.canis-major.famfo.xyz. 3600 IN    AAAA    2a0a:4cc0:c0:313f:e300::3

;; Query time: 352 msec
;; MSG SIZE  rcvd: 108



$ dig wezen.canis-major.famfo.xyz A
; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4745
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wezen.canis-major.famfo.xyz.   IN      A

;; AUTHORITY SECTION:
famfo.xyz.              3600    IN      SOA     ns1.famfo.xyz. dns.famfo.xyz. 2025108064 10800 3600 604800 3600

;; Query time: 404 msec
;; MSG SIZE  rcvd: 100

$ dig wezen.canis-major.famfo.xyz AAAA

; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48387
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wezen.canis-major.famfo.xyz.   IN      AAAA

;; ANSWER SECTION:
wezen.canis-major.famfo.xyz. 1886 IN    AAAA    2a0a:4cc0:c0:313f:e300::3

;; Query time: 184 msec
;; MSG SIZE  rcvd: 84
DNS responses on local machine 
$ dig gts.wezen.famfo.xyz A
; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33710
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gts.wezen.famfo.xyz.		IN	A

;; ANSWER SECTION:
gts.wezen.famfo.xyz.	1760	IN	CNAME	wezen.canis-major.famfo.xyz.

;; AUTHORITY SECTION:
famfo.xyz.		15	IN	SOA	ns1.famfo.xyz. dns.famfo.xyz. 2025108052 10800 3600 604800 3600

;; Query time: 7 msec
;; MSG SIZE  rcvd: 124



$dig gts.wezen.famfo.xyz AAAA
; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33636
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;gts.wezen.famfo.xyz.		IN	AAAA

;; ANSWER SECTION:
gts.wezen.famfo.xyz.	1721	IN	CNAME	wezen.canis-major.famfo.xyz.
wezen.canis-major.famfo.xyz. 1722 IN	AAAA	2a0a:4cc0:c0:313f:e300::3

;; Query time: 0 msec
;; MSG SIZE  rcvd: 108



$dig wezen.canis-major.famfo.xyz A

; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51356
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wezen.canis-major.famfo.xyz.	IN	A

;; AUTHORITY SECTION:
famfo.xyz.		15	IN	SOA	ns1.famfo.xyz. dns.famfo.xyz. 2025108052 10800 3600 604800 3600

;; Query time: 3 msec
;; MSG SIZE  rcvd: 100



$ dig wezen.canis-major.famfo.xyz AAAA

; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz AAAA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33302
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;wezen.canis-major.famfo.xyz.	IN	AAAA

;; ANSWER SECTION:
wezen.canis-major.famfo.xyz. 1671 IN	AAAA	2a0a:4cc0:c0:313f:e300::3

;; Query time: 0 msec
;; MSG SIZE  rcvd: 84

(note: the Akkoma version listed in OP is patched to use a newer Finch, but the result does not change when rolling the instance back to the default Finch version nor does it change when moving Finch to 0.19 on the local machine. At least on the local machine prod vs dev env did not make a difference)

It gets weirder: it actually works on my local machine in both `dev` and `prod` env, but not on the actual prod instance from which the above report was generated. Erlang, Elixir, etc versions are equivalent (both use Aloine 3.22 packages). DNS responses also look similar. The only difference is the local machine being x86_64 and the prod instance aarch64, but this _shouldn’t_ matter for DNS resolution. <details> <summary>DNS responses on prod instance</summary> ``` $ dig gts.wezen.famfo.xyz A ; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53430 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;gts.wezen.famfo.xyz. IN A ;; ANSWER SECTION: gts.wezen.famfo.xyz. 3597 IN CNAME wezen.canis-major.famfo.xyz. ;; AUTHORITY SECTION: famfo.xyz. 3597 IN SOA ns1.famfo.xyz. dns.famfo.xyz. 2025108060 10800 3600 604800 3600 ;; Query time: 0 msec ;; MSG SIZE rcvd: 124 $ dig gts.wezen.famfo.xyz AAAA ; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39796 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;gts.wezen.famfo.xyz. IN AAAA ;; ANSWER SECTION: gts.wezen.famfo.xyz. 3250 IN CNAME wezen.canis-major.famfo.xyz. wezen.canis-major.famfo.xyz. 3600 IN AAAA 2a0a:4cc0:c0:313f:e300::3 ;; Query time: 352 msec ;; MSG SIZE rcvd: 108 $ dig wezen.canis-major.famfo.xyz A ; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4745 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;wezen.canis-major.famfo.xyz. IN A ;; AUTHORITY SECTION: famfo.xyz. 3600 IN SOA ns1.famfo.xyz. dns.famfo.xyz. 2025108064 10800 3600 604800 3600 ;; Query time: 404 msec ;; MSG SIZE rcvd: 100 $ dig wezen.canis-major.famfo.xyz AAAA ; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48387 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;wezen.canis-major.famfo.xyz. IN AAAA ;; ANSWER SECTION: wezen.canis-major.famfo.xyz. 1886 IN AAAA 2a0a:4cc0:c0:313f:e300::3 ;; Query time: 184 msec ;; MSG SIZE rcvd: 84 ``` </details> <details> <summary>DNS responses on local machine</summary> ``` $ dig gts.wezen.famfo.xyz A ; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33710 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;gts.wezen.famfo.xyz. IN A ;; ANSWER SECTION: gts.wezen.famfo.xyz. 1760 IN CNAME wezen.canis-major.famfo.xyz. ;; AUTHORITY SECTION: famfo.xyz. 15 IN SOA ns1.famfo.xyz. dns.famfo.xyz. 2025108052 10800 3600 604800 3600 ;; Query time: 7 msec ;; MSG SIZE rcvd: 124 $dig gts.wezen.famfo.xyz AAAA ; <<>> DiG 9.20.10 <<>> gts.wezen.famfo.xyz AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33636 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;gts.wezen.famfo.xyz. IN AAAA ;; ANSWER SECTION: gts.wezen.famfo.xyz. 1721 IN CNAME wezen.canis-major.famfo.xyz. wezen.canis-major.famfo.xyz. 1722 IN AAAA 2a0a:4cc0:c0:313f:e300::3 ;; Query time: 0 msec ;; MSG SIZE rcvd: 108 $dig wezen.canis-major.famfo.xyz A ; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz A ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51356 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;wezen.canis-major.famfo.xyz. IN A ;; AUTHORITY SECTION: famfo.xyz. 15 IN SOA ns1.famfo.xyz. dns.famfo.xyz. 2025108052 10800 3600 604800 3600 ;; Query time: 3 msec ;; MSG SIZE rcvd: 100 $ dig wezen.canis-major.famfo.xyz AAAA ; <<>> DiG 9.20.10 <<>> wezen.canis-major.famfo.xyz AAAA ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33302 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;wezen.canis-major.famfo.xyz. IN AAAA ;; ANSWER SECTION: wezen.canis-major.famfo.xyz. 1671 IN AAAA 2a0a:4cc0:c0:313f:e300::3 ;; Query time: 0 msec ;; MSG SIZE rcvd: 84 ``` </details> *(note: the Akkoma version listed in OP is patched to use a newer Finch, but the result does not change when rolling the instance back to the default Finch version nor does it change when moving Finch to 0.19 on the local machine. At least on the local machine `prod` vs `dev` env did not make a difference)*
Oneric commented 2025-07-16 16:44:08 +00:00
Author
Owner
Copy link

After upgrading Tesla (and its deps) to the newest version:
Both the version with explicit and implicit client, sometimes fail and other times succeed. If it succeeded once, it usually keeps succeeding for a while suggesting the successful resolution gets cached for a while?

I cannot say whether the same occured before upgrading versions.
Either way, during normal operation, basically all my instance’s attempts to fetch something from the CNAME-IPv6 instance would run into the cold-cache case, explaining the prevalence of logs about it.

Still can’t reproduce this on the same machine with Tesla+Finch directly though

unrelated side note: we probably should set protocols: [:http2, :http1] in our Finch pool opts to not force HTTP1. Though unless we go HTTP2-only (which might cause interop issues) we won’t get multiplexing

After upgrading Tesla (and its deps) to the newest version: Both the version with explicit and implicit `client`, _sometimes_ fail and other times succeed. If it succeeded once, it usually keeps succeeding for a while suggesting the successful resolution gets cached for a while? I cannot say whether the same occured before upgrading versions. Either way, during normal operation, basically all my instance’s attempts to fetch something from the CNAME-IPv6 instance would run into the cold-cache case, explaining the prevalence of logs about it. Still can’t reproduce this on the same machine with `Tesla+Finch` directly though unrelated side note: we probably should set `protocols: [:http2, :http1]` in our Finch pool opts to not _force_ HTTP1. Though unless we go HTTP2-only *(which might cause interop issues)* we won’t get multiplexing
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
translations
ci-builds-otp28
stable
ci
otp28
backfill-expiry
db-prune-beastmode-level-aggression
better-stats
customizable-docker-db
static-adminfe
bad-uploader-config-warning
docker
user-expiry-backfill
config-db-keys
ensure-scrubbers-loaded
otp26
code-shaking-does-not-go-brr
elixir1.15
circleci
backup-fixes
mod-task
policy
mrf-coolness
frontend-switcher-9000
contentMap
language-on-posts
rabbit
credo-on-pr
unify-http
normalise-markup-by-default
buildx
v3.17.0
v3.16.0
v3.15.2
v3.15.1
v3.15.0
v3.14.1
v3.14.0
v2.8.0
v2.7.1
v3.13.3
v2.7.0
v3.13.2
v2.6.3
v3.13.1
v3.13.0
snac-3.12.1.2
v3.12.2
snac-3.12.1.1
v3.12.1
v3.12.0
v3.11.0
v2.6.2
v2.6.1
2.6.1
v2.6.0
v2.5.5
v3.10.4
v3.10.3
v3.10.2
v3.10.1
v3.10.0
v2.5.4
v2.5.3
v3.9.3
v3.9.2
v3.9.1
V3.9.0
2023.05
v3.8.0
v3.7.1
v3.7.0
v3.6.0
v3.5.0
v2.4.5
v3.4.0
v3.3.1
v2.4.4
v3.3.0
v3.2.3
v3.2.2
v3.2.1
stable-202209
v3.2.0
v3.1.0
stable-2022.07
v3.0.0
v0.0.1
v2.5.2-6
v2.5.2-5
v2.5.2-4
v2.5.2-3
v2.5.2-2
v2.5.2-1
v2.5.2
v2.5.1
v2.5.0-8
v2.5.0-7
v2.5.0-6
v2.5.0-5
v2.5.0-4
v2.5.0-3
v2.5.0-2
v2.5.0-1
v2.5.0
v2.4.3
pre-rebase
v2.4.2
v2.4.1
v2.4.0
soapbox-v1.1.1
soapbox-v1.1.0
soapbox-v1.0.0
v2.3.0
v2.2.2
v2.2.1
v2.2.0
v2.1.2
v2.1.1
v2.1.0
v2.0.7
v2.0.6
v2.0.5
v2.0.4
v2.0.3
v2.0.2
v2.0.1
v2.0.0
v1.1.9
v1.1.8
v1.1.7
v1.1.6
v1.1.5
v1.1.4
v1.1.3
v1.1.2
v1.1.1
v1.1.0
v1.0.91
v1.0.90
v1.0.7
v1.0.6
v1.0.5
v1.0.4
v1.0.3
v1.0.2
v1.0.1
v1.0.0
v0.9.0
Labels
Clear labels   
approved, awaiting change

   
broken setup

Issue arose from a misconfiguration by the admin, custom patches, manual db edits or similar

  
bug

Something is not working

  
cannot reproduce

   
configuration

This requires config changes

  
documentation

This is about human-readable docs

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
extremely low priority

   
feature request

Something new?

  
Fix it yourself

Support has been attempted

  
help wanted

Need some help

  
invalid

Something is wrong

  
mastodon_api

   
needs change/feedback

Issue or PR is stalled on response from the author or a third party

  
needs docs

   
needs tests

   
not a bug

   
not our bug

Bug in a dependency of ours (meaning we can't just fix it), or in another AP implementation or client interfacing with Akkoma (which needs to be fixed on their end)

  
planned

   
pleroma_api

   
privacy

   
question

More information is needed

  
static_fe

   
triage

   
wontfix

This won't be fixed

No labels
approved, awaiting change
broken setup
bug
cannot reproduce
configuration
documentation
duplicate
enhancement
extremely low priority
feature request
Fix it yourself
help wanted
invalid
mastodon_api
needs change/feedback
needs docs
needs tests
not a bug
not our bug
planned
pleroma_api
privacy
question
static_fe
triage
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
AkkomaGang/akkoma#947
No description provided.