Multi-edit notification silently fails validation when content exceeds 1024 chars (string_too_long)

[Marvelous2095]

Description

When performing a "Multi edit" bulk action on several devices via the web UI, the generated in-app notification summary (listing all affected MAC addresses) can exceed the 1024-character limit enforced by the CreateNotificationRequest Pydantic model. Instead of being truncated, the write is rejected with a validation error and the notification is silently dropped — the underlying device edit itself succeeds, but no record of the bulk action appears in the notification/message center.

Steps to reproduce

1. Select enough devices (roughly 15+, depending on MAC/name length) in the Devices view.
2. Perform a "Multi edit" action (e.g. bulk update a field) on all of them at once.
3. Check the application logs.

Observed log output

[Validation] Error for write_notification: 1 validation error for CreateNotificationRequest
content
  String should have at most 1024 characters [type=string_too_long, input_value='[Multi edit] Executed "u...3:02,9c:8d:7c:30:fc:0d"', input_type=str]
    For further information visit https://errors.pydantic.dev/2.13/v/string_too_long

This occurred twice within a couple of minutes of each other while doing two separate bulk multi-edit actions.

Expected behavior

The notification content should be truncated (e.g. to 1024 chars, with an ellipsis or a summary like "and N more devices") instead of being rejected outright and lost. A failed multi-edit summary notification means there's no audit trail of what was changed in bulk.

Environment

• Image: ghcr.io/netalertx/netalertx:latest (digest sha256:0ee5cdcaa8a84bfd2f31354b4b30e603804d124821055b9942dcffb52d2ce4bc, pulled ~2 weeks before report)
• Deployment: Docker (docker compose), Ubuntu host

Suggested fix

Truncate the content field server-side before constructing CreateNotificationRequest (or raise the max_length for this specific notification type / summarize instead of listing every MAC individually) rather than letting Pydantic validation reject the whole write.

[jokob-sk]

This should be available/fixed in the next release.
It would be great if you could test the ghcr.io/netalertx/netalertx-dev / ghcr.io/netalertx/netalertx-dev-unsafe Docker image in ~15 minutes (or once the latest GitHub Action finishes).

⚠️ Please back up everything first, or ideally spin up a separate container (make sure you use a unique PORT and GRAPHQL_PORT if running instances concurrently) with its own DB and config (a copy of your current setup), as database changes may occur.

After updating:

• Click the 🔄 refresh button in the blue header at the top
• Hard refresh your browser cache (shift + reload) to force js and css files reload

Disclaimer: Running the dev container long-term may lead to data loss, as upgrade paths are not guaranteed.

Thanks in advance,
j

[Marvelous2095]

Tested ghcr.io/netalertx/netalertx-dev as requested, in an isolated container with its own fresh config/DB (host networking + required capabilities, no shared state with any production instance).

Confirmed fixed in server/api_server/openapi/schemas.py:

class CreateNotificationRequest(BaseModel):
    content: str = Field(..., min_length=1, max_length=4096, ...)

    @field_validator("content", mode="before")
    @classmethod
    def truncate_content(cls, v):
        if isinstance(v, str) and len(v) > 4096:
            return v[:4093] + "..."
        return v

Ran it live against the validator directly (5000-char input):

Eingabelänge: 5000
Gespeicherte Länge: 4096
Endet mit: 'AAAAAAA...'
Erfolgreich erstellt, keine Exception geworfen: JA

Truncates to 4096 chars ending in ... instead of raising a string_too_long validation error — exactly resolves the original issue where a large multi-edit's generated summary lost the whole notification write. Thanks for the quick turnaround!

[jokob-sk]

Thanks for testing and glad it's resolved. If you find NetAlertX useful, consider sharing the app on forums or socials, at your work, or share a quick review on Reddit or elsewhere to help support the project. See more ideas and how-to in the growth playbook.

I'll keep the issue open until released to production.