starred/documenso

Fork 0

mirror of https://github.com/documenso/documenso.git synced 2026-04-24 21:36:01 +03:00

[GH-ISSUE #2061] Some documents in state completed others in pending #592

New issue

Open

opened 2026-02-26 18:47:43 +03:00 by kerem · 7 comments

kerem commented

2026-02-26 18:47:43 +03:00

Owner

Originally created by @JArdissone on GitHub (Oct 3, 2025).
Original GitHub issue: https://github.com/documenso/documenso/issues/2061

Issue Description

I have some documents that, after all users sign them, remain stuck in a pending status. Other documents uploaded later are signed without any problem, so I don’t believe this is a certificate issue, since the signing process works correctly with other files.

I tried to force the signing process with the following query:
documenso=> UPDATE "BackgroundJob"
SET
"lastRetriedAt" = NULL, -- Clears the last run time, which is key for forcing an immediate retry
"updatedAt" = NOW()
WHERE
name = 'Seal Document'
AND status = 'PENDING'
AND (payload->>'documentId') IS NOT NULL;

It reports UPDATE 22, but nothing happens — the documents remain in pending status.

I also tried restarting/forcing the worker with:
nohup npm run with:env -- npx trigger-cli dev --handler-path="/api/jobs" > /home/sysadmin/documenso/documenso/inngest-worker.log 2>&1 &

and

nohup npm run with:env -- npx trigger-cli start --handler-path="/api/jobs" > /home/sysadmin/documenso/documenso/inngest-worker.log 2>&1 &

But neither resolved the issue.

I’ve noticed that Prisma times out when processing documents larger than ~5 MB due to the time it takes to handle them. For example, a document that originally was only 1 MB grows significantly once the certificate and audit trail are embedded — in some cases reaching 3–5 MB even with only two signers.

This seems to be the reason some documents remain in pending status, while smaller ones process without issue.

Could someone provide a clear guide on how to properly increase the Prisma client timeout so that jobs for larger files have enough time to complete?

Steps to Reproduce

Normal singing process with 4 singers

Expected Behavior

No response

Current Behavior

No response

Screenshots (optional)

Operating System [e.g., Windows 10]

Ubuntu 24.04.3 LTS

Browser [e.g., Chrome, Firefox]

Chrome

Version [e.g., 2.0.1]

No response

Please check the boxes that apply to this issue report.

I have searched the existing issues to make sure this is not a duplicate.
I have provided steps to reproduce the issue.
I have included relevant environment information.
I have included any relevant screenshots.
I understand that this is a voluntary contribution and that there is no guarantee of resolution.
I want to work on creating a PR for this issue if approved

Originally created by @JArdissone on GitHub (Oct 3, 2025). Original GitHub issue: https://github.com/documenso/documenso/issues/2061 ### Issue Description I have some documents that, after all users sign them, remain stuck in a pending status. Other documents uploaded later are signed without any problem, so I don’t believe this is a certificate issue, since the signing process works correctly with other files. I tried to force the signing process with the following query: documenso=> UPDATE "BackgroundJob" SET "lastRetriedAt" = NULL, -- Clears the last run time, which is key for forcing an immediate retry "updatedAt" = NOW() WHERE name = 'Seal Document' AND status = 'PENDING' AND (payload->>'documentId') IS NOT NULL; It reports UPDATE 22, but nothing happens — the documents remain in pending status. I also tried restarting/forcing the worker with: nohup npm run with:env -- npx trigger-cli dev --handler-path="/api/jobs" > /home/sysadmin/documenso/documenso/inngest-worker.log 2>&1 & and nohup npm run with:env -- npx trigger-cli start --handler-path="/api/jobs" > /home/sysadmin/documenso/documenso/inngest-worker.log 2>&1 & But neither resolved the issue. I’ve noticed that Prisma times out when processing documents larger than ~5 MB due to the time it takes to handle them. For example, a document that originally was only 1 MB grows significantly once the certificate and audit trail are embedded — in some cases reaching 3–5 MB even with only two signers. This seems to be the reason some documents remain in pending status, while smaller ones process without issue. Could someone provide a clear guide on how to properly increase the Prisma client timeout so that jobs for larger files have enough time to complete? ### Steps to Reproduce Normal singing process with 4 singers ### Expected Behavior _No response_ ### Current Behavior _No response_ ### Screenshots (optional) <img width="1382" height="193" alt="Image" src="https://github.com/user-attachments/assets/81d5951d-37f9-4fb2-b21a-be9b9bb7421b" /> ### Operating System [e.g., Windows 10] Ubuntu 24.04.3 LTS ### Browser [e.g., Chrome, Firefox] Chrome ### Version [e.g., 2.0.1] _No response_ ### Please check the boxes that apply to this issue report. - [x] I have searched the existing issues to make sure this is not a duplicate. - [x] I have provided steps to reproduce the issue. - [x] I have included relevant environment information. - [x] I have included any relevant screenshots. - [x] I understand that this is a voluntary contribution and that there is no guarantee of resolution. - [x] I want to work on creating a PR for this issue if approved

kerem added the

Stale

status: triage

labels

2026-02-26 18:47:43 +03:00

kerem commented

2026-02-26 18:47:43 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 3, 2025):

Thank you for opening your first issue and for being a part of the open signing revolution!

One of our team members will review it and get back to you as soon as it possible 💚

Meanwhile, please feel free to hop into our community in Discord

@github-actions[bot] commented on GitHub (Oct 3, 2025): Thank you for opening your first issue and for being a part of the open signing revolution! <br /> One of our team members will review it and get back to you as soon as it possible 💚 <br /> Meanwhile, please feel free to hop into our community in [Discord](https://documen.so/discord)

kerem commented

2026-02-26 18:47:43 +03:00

Author

Owner

@Novapixel1010 commented on GitHub (Oct 10, 2025):

I am curious if you reduce the sign of the document and change nothing else. Would it work? If so then this would prove more this is a timeout issue. If you can provide the document that be great.

@Novapixel1010 commented on GitHub (Oct 10, 2025): I am curious if you reduce the sign of the document and change nothing else. Would it work? If so then this would prove more this is a timeout issue. If you can provide the document that be great.

kerem commented

2026-02-26 18:47:43 +03:00

Author

Owner

@seabro commented on GitHub (Oct 13, 2025):

I have the same issue with all signing documents. It doesn't matter if is 2 or 4 people for siging, document is stuck in pending state

@seabro commented on GitHub (Oct 13, 2025): I have the same issue with all signing documents. It doesn't matter if is 2 or 4 people for siging, document is stuck in pending state

kerem commented

2026-02-26 18:47:43 +03:00

Author

Owner

@Novapixel1010 commented on GitHub (Oct 18, 2025):

Have you taken a look at #1634 maybe that's related

@Novapixel1010 commented on GitHub (Oct 18, 2025): Have you taken a look at #1634 maybe that's related

kerem commented

2026-02-26 18:47:44 +03:00

Author

Owner

@seabro commented on GitHub (Oct 20, 2025):

Have you taken a look at #1634 maybe that's related

Yep, for me it was the certificate related. After creation of self-signed cerificate evenrything worked fine

@seabro commented on GitHub (Oct 20, 2025): > Have you taken a look at [#1634](https://github.com/documenso/documenso/issues/1634) maybe that's related Yep, for me it was the certificate related. After creation of self-signed cerificate evenrything worked fine

kerem commented

2026-02-26 18:47:44 +03:00

Author

Owner

@Somchit-cmd commented on GitHub (Oct 22, 2025):

Have you taken a look at #1634 maybe that's related

Yep, for me it was the certificate related. After creation of self-signed cerificate evenrything worked fine

what solution do you use to fix this issue

@Somchit-cmd commented on GitHub (Oct 22, 2025): > > Have you taken a look at [#1634](https://github.com/documenso/documenso/issues/1634) maybe that's related > > Yep, for me it was the certificate related. After creation of self-signed cerificate evenrything worked fine what solution do you use to fix this issue

kerem commented

2026-02-26 18:47:44 +03:00

Author

Owner

@seabro commented on GitHub (Oct 22, 2025):

Follow the instructions on docs: https://docs.documenso.com/developers/self-hosting/signing-certificate and create certificate, then update .env file with certificate data

@seabro commented on GitHub (Oct 22, 2025): Follow the instructions on docs: https://docs.documenso.com/developers/self-hosting/signing-certificate and create certificate, then update .env file with certificate data

No milestone

No project

No assignees

1 participant

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

starred/documenso#592

No description provided.

Rows
Columns