fix(core): Use maxValueLength in extra error data integration by AbhiPrasad · Pull Request #12174 · getsentry/sentry-javascript

AbhiPrasad · 2024-05-22T18:00:20Z

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad · 2024-05-22T18:00:20Z

fixes#12168

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad · 2024-05-22T18:00:20Z

fixes#12168

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad · 2024-05-22T18:00:20Z

fixes#12168

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad · 2024-05-22T18:00:20Z

fixes#12168

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad · 2024-05-22T18:00:20Z

fixes#12168

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad · 2024-05-22T18:00:20Z

fixes#12168

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad · 2024-05-22T18:00:20Z

fixes#12168

We should truncate extra error data keys using maxValueLength to make sure event payload size stays reasonably small.

AbhiPrasad · 2024-05-22T18:03:08Z

 }
 const value = error[key];
- extraErrorInfo[key] = isError(value) ? value.toString() : value;
+ extraErrorInfo[key] = truncate(isError(value) ? value.toString() : value, maxValueLength);


Actually now that I'm looking at this again, const value = error[key] means that value could be anything. What is the cleanest way here to make sure we truncate all the string? Should I adjust the normalize function?

I think we can just do something like this:
Suggested change
extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
extraErrorInfo[key]=isError(value)||typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;
?

The issue here is that it'll only truncate string values at the top-most level. String values that are nested within an object will not get truncated.

Hmm I see. Yeah then if we want to fix this I guess we have to update normalize to also handle max value length!

Given the normalize update will mean refactoring how base client and event processing works, I'm electing for the quick fix and just using your change on the extraErrorInfo[key] setter. This also unblocks the user.
I will create a GH issue and write down what we need to do to make a more robust fix.

WesCossick · 2024-06-11T13:27:21Z

Any update on this? We're starting to retroactively discover more and more lost errors that our engineering team needs to be aware of due to this bug.

AbhiPrasad · 2024-06-12T18:09:01Z

Hi @WesCossick sorry for the delay - there were some other items that took my attention away from this recently. I will try to get to this tomorrow and release by next week.

The source of the problems are the extraErrorDataIntegration integration. For now I recommend removing this integration to make sure you get no errors dropped.

As another workaround, you can make sure that the fields set by extraErrorDataIntegration on the sentry event are trimmed accordingly via the beforeSend option in Sentry.init.

lforst · 2024-06-19T11:32:08Z

Am I dumb or could we use our normalizeToSize() function to truncate the extra data to a sane length?

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

AbhiPrasad requested review from a team, andreiborza and mydea and removed request for a teamMay 22, 2024 18:00

AbhiPrasad self-assigned this May 22, 2024

AbhiPrasad mentioned this pull request May 22, 2024
extraErrorDataIntegration leads to large events #12168
Closed
3 tasks

AbhiPrasad commented May 22, 2024
View reviewed changes

AbhiPrasad added 2 commits June 17, 2024 09:40

fix(core): Use maxValueLength in extra error data integration
60a6112

Use simple normalize
6cca211

AbhiPrasad force-pushed the abhi-extraerrordata-max-length branch from 1bdace8 to 6cca211Compare June 17, 2024 14:26

Merge branch 'develop' into abhi-extraerrordata-max-length
56b2410

mydea approved these changes Jun 19, 2024
View reviewed changes

mydea merged commit 2fbd7cc into developJun 19, 2024

mydea deleted the abhi-extraerrordata-max-length branch June 19, 2024 09:17

gokulk16 mentioned this pull request Jul 11, 2024
[Snyk] Upgrade @sentry/browser from 8.8.0 to 8.10.0 gokulk16/type-to-calculate-web#30
Merged

FengShangWuQi mentioned this pull request Jul 14, 2024
[Snyk] Upgrade @sentry/gatsby from 7.20.0 to 8.11.0 FengShangWuQi/fengshangwuqi.github.io#1908
Closed

	extraErrorInfo[key]=truncate(isError(value)? value.toString() : value,maxValueLength);
	extraErrorInfo[key]=isError(value)\|\|typeofvalue==='string' ? truncate(`${value}`,maxValueLength) : value;

Uh oh!

Uh oh!

Conversation

AbhiPrasad commented May 22, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WesCossick commented Jun 11, 2024

Uh oh!

AbhiPrasad commented Jun 12, 2024

Uh oh!

lforst commented Jun 19, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

AbhiPrasad commented May 22, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WesCossick commented Jun 11, 2024

Uh oh!

AbhiPrasad commented Jun 12, 2024

Uh oh!

lforst commented Jun 19, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

AbhiPrasad commented May 22, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WesCossick commented Jun 11, 2024

Uh oh!

AbhiPrasad commented Jun 12, 2024

Uh oh!

AbhiPrasad commented May 22, 2024•
edited
Loading

AbhiPrasad commented May 22, 2024•
edited
Loading

AbhiPrasad commented May 22, 2024•
edited
Loading

AbhiPrasad commented May 22, 2024•
edited
Loading