Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error message truncation may be too strict #13046

Closed
remcowesterhoud opened this issue Jun 9, 2023 · 4 comments · Fixed by #13414
Closed

Error message truncation may be too strict #13046

remcowesterhoud opened this issue Jun 9, 2023 · 4 comments · Fixed by #13414
Assignees
Labels
area/ux Marks an issue as related to improving the user experience good first issue Marks an issue as simple enough for first time contributors kind/bug Categorizes an issue or PR as a bug onboarding severity/low Marks a bug as having little to no noticeable impact for the user support Marks an issue as related to a customer support request version:8.1.15 Marks an issue as being completely or in parts released in 8.1.15 version:8.2.9 Marks an issue as being completely or in parts released in 8.2.9 version:8.3.0-alpha4 Marks an issue as being completely or in parts released in 8.3.0-alpha4 version:8.3.0 Marks an issue as being completely or in parts released in 8.3.0

Comments

@remcowesterhoud
Copy link
Contributor

remcowesterhoud commented Jun 9, 2023

Describe the bug

In #11460 we've implemented a truncation on error messages. This was done to prevent error messages from exceeding the maximum message size. Currently the messages are limited to 500 characters.

We've had a support case asking us where the remainder of the error message has gone. 500 characters may be too strict. A regular stack trace will quickly exceed this limit.

Generally users would have logging on their workers which should be able to show them the full message. Obviously this isn't visible in Operate and is an extra step for users. If we could provide a better UX by increasing this limit we should consider this.

We could also think about making this limit configurable.

To Reproduce

Throw an error on a Job with > 500 characters.

Expected behavior

I can see more than just the first 500 characters of my error.


https://jira.camunda.com/browse/SUPPORT-17090

@remcowesterhoud remcowesterhoud added kind/bug Categorizes an issue or PR as a bug kind/feature Categorizes an issue or PR as a feature, i.e. new behavior and removed kind/bug Categorizes an issue or PR as a bug labels Jun 9, 2023
@github-actions github-actions bot added the support Marks an issue as related to a customer support request label Jun 9, 2023
@korthout
Copy link
Member

ZPA triage:

  • request makes sense
  • we could easily increase the limit much higher (e.g. 10k) without exceeding MAX_MESSAGE_SIZE
  • we could also consider ways to make this more dynamic, but this is more complex
  • the simple fix has our preference and could be backported to all supported versions easily
  • we'll mark this a bug
  • could be a good first issue for new onboarders

@korthout korthout added kind/bug Categorizes an issue or PR as a bug severity/low Marks a bug as having little to no noticeable impact for the user good first issue Marks an issue as simple enough for first time contributors onboarding and removed kind/feature Categorizes an issue or PR as a feature, i.e. new behavior labels Jun 14, 2023
@akkie
Copy link

akkie commented Jul 3, 2023

The support also pointed me to this issue. I work for a consulting company and we helped a large German corporation to implement Camunda Platform 8 for their processes. In all our presentations, we showed how easy it is for the DevOps guys to see the errors directly in Operate instead of searching through the logs. Of course this was not the only selling point, but it was a feature that everyone really liked.

I understand the problem for truncating the message, but as @korthout mentioned, if it's ok to increase the limit, it would be really appreciated, because currently with the 500 chars limit, it's not really useful. For us 10k would be more as enough.

@korthout korthout added the area/ux Marks an issue as related to improving the user experience label Jul 3, 2023
@korthout
Copy link
Member

korthout commented Jul 3, 2023

Thanks for sharing @akkie. It's very helpful to understand such perspectives 🙇

@aleksander-dytko
Copy link
Contributor

Another Support issue about this: https://jira.camunda.com/browse/SUPPORT-17503

It would be great to finish this soon. Thank @nicpuppa for taking care of this one 🚀

@ghost ghost closed this as completed in 0175845 Jul 12, 2023
ghost pushed a commit that referenced this issue Jul 12, 2023
13461: [Backport stable/8.2] Increase error message truncation limit r=nicpuppa a=backport-action

# Description
Backport of #13414 to `stable/8.2`.

relates to #13046

Co-authored-by: Nicola Puppa <[email protected]>
ghost pushed a commit that referenced this issue Jul 13, 2023
13467: [Backport stable/8.0] Increase error message truncation limit r=remcowesterhoud a=nicpuppa

Backport of #13414 to `stable/8.0`

relates to #13046 

Co-authored-by: Nicola Puppa <[email protected]>
ghost pushed a commit that referenced this issue Jul 13, 2023
13468: [Backport stable/8.1] Increase error message truncation limit r=remcowesterhoud a=nicpuppa

Backport of #13414  to `stable/8.1`

relates to #13046

Co-authored-by: Nicola Puppa <[email protected]>
ghost pushed a commit that referenced this issue Jul 13, 2023
13468: [Backport stable/8.1] Increase error message truncation limit r=remcowesterhoud a=nicpuppa

Backport of #13414  to `stable/8.1`

relates to #13046

Co-authored-by: Nicola Puppa <[email protected]>
ghost pushed a commit that referenced this issue Jul 13, 2023
13468: [Backport stable/8.1] Increase error message truncation limit r=remcowesterhoud a=nicpuppa

Backport of #13414  to `stable/8.1`

relates to #13046

Co-authored-by: Nicola Puppa <[email protected]>
@megglos megglos added version:8.2.9 Marks an issue as being completely or in parts released in 8.2.9 version:8.3.0-alpha4 Marks an issue as being completely or in parts released in 8.3.0-alpha4 release/8.0.19 labels Jul 26, 2023
@abbasadel abbasadel added the version:8.1.15 Marks an issue as being completely or in parts released in 8.1.15 label Aug 2, 2023
@megglos megglos added the version:8.3.0 Marks an issue as being completely or in parts released in 8.3.0 label Oct 5, 2023
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ux Marks an issue as related to improving the user experience good first issue Marks an issue as simple enough for first time contributors kind/bug Categorizes an issue or PR as a bug onboarding severity/low Marks a bug as having little to no noticeable impact for the user support Marks an issue as related to a customer support request version:8.1.15 Marks an issue as being completely or in parts released in 8.1.15 version:8.2.9 Marks an issue as being completely or in parts released in 8.2.9 version:8.3.0-alpha4 Marks an issue as being completely or in parts released in 8.3.0-alpha4 version:8.3.0 Marks an issue as being completely or in parts released in 8.3.0
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants