[Bug]: Remote community imports can hit community.title VARCHAR(50), coinciding with severe federation resource usage on 1.0.0-beta.1

Requirements

• Is this a bug report? For questions or discussions use https://lemmy.ml/c/lemmy_support or the matrix chat.
• Did you check to see if this issue already exists?
• Is this only a single bug? Do not put multiple bugs in one issue.
• Do you agree to follow the rules in our Code of Conduct?
• Is this a backend issue? Use the lemmy-ui repo for UI / frontend issues.

Summary

Remote community imports can hit community.title VARCHAR(50), coinciding with severe federation resource usage on 1.0.0-beta.1

Summary

On a fresh Lemmy 1.0.0-beta.1 instance, federation/import activity produced repeated PostgreSQL errors because remote community titles exceeded the community.title VARCHAR(50) schema constraint.

During the same federation/import burst, Lemmy, pict-rs, and PostgreSQL resource usage increased dramatically, Lemmy UI SSR requests took 60–75 seconds, and nginx began returning 504 Gateway Time-out.

Once the activity subsided / federation was disabled through the admin UI, the exact same installation returned to ~0.1 second response times and negligible CPU usage.

I have not established that the VARCHAR(50) error itself causes the resource spike, so I'm reporting these as correlated observations.

Environment

• Lemmy backend: 1.0.0-beta.1
• Lemmy UI: 1.0.0-beta.1
• pict-rs: 0.5.24
• PostgreSQL: 18.4
• PostgreSQL image: pgautoupgrade/pgautoupgrade:18-alpine
• nginx internal proxy
• Caddy external reverse proxy
• Docker Engine: 29.3.1
• Docker Compose: v5.1.1
• Host: macOS 15.7.9 / x86_64
• Hardware: 6-core Intel CPU / 32 GB RAM
• Docker VM allocation: ~7.7 GB RAM
• New instance with one local user

Database constraint

On this fresh 1.0.0-beta.1 database:

SELECT
  column_name,
  data_type,
  character_maximum_length,
  is_nullable
FROM information_schema.columns
WHERE table_name = 'community'
  AND column_name = 'title';

returns:

column_name | data_type         | character_maximum_length | is_nullable
------------+-------------------+--------------------------+------------
title       | character varying | 50                       | YES

community.title is the only VARCHAR(50) column in the community table.

Federation import errors

During the problem period PostgreSQL repeatedly logged:

ERROR: value too long for type character varying(50)

The failing statement was an insert/upsert into community:

INSERT INTO "community"
(
  "instance_id",
  "name",
  "title",
  "public_key",
  "sidebar",
  ...
)
VALUES (...)
ON CONFLICT ("ap_id")
...

The errors appeared repeatedly while Lemmy was discovering/importing federated communities.

Successfully imported remote community titles demonstrate that values close to the limit work normally:

46  Scienze Naturali, Scoperte Scientifiche, Meteo
42  Pilzzucht - Alles zum Heimanbau von Pilzen
41  Fediverso - social federati indipendenti
39  Foto - immagini, tool liberi e Pixelfed
35  Treffpunkt Digitales Weichenstellen

I attempted to enable full PostgreSQL parameter logging to capture the exact rejected remote title, but the error did not recur during the subsequent controlled observation period.

Federation state

At the time of testing the instance had discovered approximately:

88 federated instances
93 remote communities

The federation subsystem reported:

Federating to 88/88 instances (0 dead, 0 disallowed)

A sample of federation_queue_state showed fail_count = 0, so there was no obvious persistent outbound retry storm after the instance had stabilized.

Resource usage during the failure

At the peak of the problem:

lemmy:
CPU: ~120–136%
RAM: ~1.0–1.5 GB

pict-rs:
CPU: ~399%
RAM: ~3.86 GB

postgres:
CPU: ~83%
RAM: ~380 MB

pict-rs alone consumed roughly half of the Docker VM's available RAM.

The Lemmy UI became unhealthy because its healthcheck repeatedly exceeded its 10-second timeout.

nginx logged:

upstream timed out (110: Operation timed out)
while reading response header from upstream

and returned:

504 Gateway Time-out

Measured response times during failure

Initially:

GET /api/v3/site: ~39 seconds
GET /: ~7 seconds

A request directly from the nginx container to lemmy-ui:1234 later took approximately 75 seconds.

Requests to /admin exceeded nginx's timeout and returned 504.

Stopping pict-rs reduced but did not eliminate the slowdown:

API: ~3.4 seconds
Web UI: ~61 seconds -> HTTP 504

This suggests pict-rs contributed heavily to the resource exhaustion, but backend/federation work was also involved.

Baseline after recovery

With the federation/import burst no longer occurring, without changing hardware or PostgreSQL tuning:

lemmy:
CPU: ~0–2%
RAM: ~116 MB

pict-rs:
CPU: ~0.3%
RAM: ~39 MB

postgres:
RAM: ~141 MB

Measured locally through the same nginx proxy:

GET /api/v4/site: 0.086 seconds
GET /: 0.135 seconds

The Lemmy UI healthcheck returned to healthy.

Other federation observations

During the problematic period the server was processing remote ActivityPub traffic from Lemmy, PieFed, Mastodon, and other implementations.

Logs included remote-community requests such as:

/c/[email protected]
/c/[email protected]

along with remote post/object fetching.

Expected behavior

A remote ActivityPub community having a display title longer than 50 characters should not repeatedly fail against the local database in a way that can contribute to significant federation workload.

Ideally Lemmy should either:

• support remote community titles longer than 50 characters,
• normalize/truncate them safely, or
• reject the individual remote object cleanly without repeated expensive processing.

Separately, a small amount of federation/discovery activity on a nearly empty instance should not result in multi-core pict-rs CPU utilization, several GB of RAM consumption, and minute-long SSR responses.

Questions

1. Is community.title VARCHAR(50) intentional for federated communities in Lemmy 1.0?
2. Should ActivityPub community/group names from other implementations be permitted to exceed the local community-title constraint?
3. Can a failed community import be retried or refetched in a way that causes substantial repeated work?
4. Is the extreme pict-rs workload likely related to remote image processing during community discovery?
5. Is there a more targeted tracing category I can enable to capture the exact remote ActivityPub object if this recurs?

I still have the test instance available and can collect additional diagnostics or reproduce against a specific remote object if useful.

Steps to Reproduce

1. Install a fresh Lemmy 1.0.0-beta.1 instance using Docker Compose with:

   • Lemmy backend 1.0.0-beta.1
   • Lemmy UI 1.0.0-beta.1
   • pict-rs 0.5.24
   • PostgreSQL 18

2. Complete the initial Lemmy setup and create the first local/admin user.

3. Enable federation in the Lemmy admin settings.

4. Begin discovering/browsing federated content and allow the instance to fetch remote communities and ActivityPub objects.

5. Allow federation activity to run for a period of time. In my case, the new instance discovered approximately 88 remote instances and 93 remote communities.

6. Observe PostgreSQL logs. During remote community imports, repeated errors appear:

   ERROR: value too long for type character varying(50)

   The failing statements are inserts/upserts into the community table.

7. Observe resource usage with docker stats. During the same federation/import activity, I observed approximately:

   • Lemmy: 120–136% CPU, 1.0–1.5 GB RAM
   • pict-rs: ~399% CPU, ~3.86 GB RAM
   • PostgreSQL: ~83% CPU

8. Attempt to load the Lemmy web UI. SSR response times progressively increase, with requests to lemmy-ui:1234 taking up to ~75 seconds.

9. Eventually nginx begins returning 504 Gateway Time-out, and the Lemmy UI Docker healthcheck becomes unhealthy because requests exceed its 10-second timeout.

10. Disable federation through the Lemmy admin settings and allow the federation/import activity to subside.

11. Repeat the same local requests. On the same installation and hardware, performance returns to approximately:

    • GET /api/v4/site: 0.086 seconds
    • GET /: 0.135 seconds
    • Lemmy: ~0–2% CPU / ~116 MB RAM
    • pict-rs: ~0.3% CPU / ~39 MB RAM

12. Query the database schema and confirm that community.title is character varying(50). It is the only VARCHAR(50) column in the community table.

Note: I have confirmed that the PostgreSQL VARCHAR(50) errors and severe resource usage occur during the same federation/import activity, but I have not established that the database constraint itself causes the resource spike.

Technical Details

OS / environment

Host OS: macOS 15.7.9 (24G830), x86_64

Hardware:

• Intel 3 GHz 6-core CPU
• 32 GB physical RAM

Docker:

• Docker Engine 29.3.1
• Docker Compose v5.1.1
• Docker Desktop VM memory allocation: ~7.7 GB

Lemmy stack:

• Lemmy backend: 1.0.0-beta.1
• Lemmy UI: 1.0.0-beta.1
• pict-rs: 0.5.24
• PostgreSQL: 18.4 (pgautoupgrade/pgautoupgrade:18-alpine)
• nginx internal reverse proxy
• Caddy external reverse proxy

Relevant server errors

During the federation/import problem, PostgreSQL repeatedly logged:

ERROR: value too long for type character varying(50)

The failing SQL operation was an INSERT/UPSERT into the community table, including the title field.

I subsequently queried the schema and confirmed:

community.title = character varying(50)

and it is the only VARCHAR(50) field in the community table.

During the performance failure nginx also reported:

upstream timed out (110: Operation timed out) while reading response header from upstream

Requests to /admin subsequently returned HTTP 504.

The Lemmy UI container's health check reported:

Health check exceeded timeout (10s)

Browser console

I did not observe or capture any browser-console error that appeared to be the cause of the failure.

The problem was reproducible at the server level without the browser: local curl requests through the internal nginx proxy slowed dramatically and eventually returned HTTP 504.

For example, during the failure a direct request from nginx to lemmy-ui:1234 took approximately 75 seconds. After the federation/import activity subsided, the same web stack returned responses in approximately 0.1 seconds.

Logs

I have additional Docker logs from the failure available and can provide a focused log excerpt if useful. I have not attached the complete raw log because the instance is publicly accessible and the full log includes unrelated ActivityPub requests, crawler/scanner traffic, and other request metadata.

Version

Lemmy backend: 1.0.0-beta.1

Lemmy Instance URL

No response