nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Survey123 webhook attachment payload URL objectid is getting notated

ChristopherCounsell

Hi,

We've noticed that Survey123 webhook payloads are coming into MAKE (Integromat) with notated objectids in the URLs. It doesn't happen for every survey but is causing issues when said URL is attempted to be used in HTTP request modules.

Is anyone else seeing this or can shed some light as to why this behaviour has started occurring?

@ZacharySutherby

2.98862e+06 should be
2988616

Encuentra más publicaciones etiquetadas con

Accepted answers

sosero

@ChristopherCounsell @abureaux

We have logged this issue as a bug and our Survey123 team is aware of the issue. Here is the Bug number, and we will wait for it to be addressed: BUG-000171796.

All comments

ChristopherCounsell

This bug was fixed 12 months ago. If you're seeing it again it's possible came back or it's something new.

I'd suggest lodging a new support ticket. You can cite this post and the defect number to help with the behaviour but it'll probably be viewed as a new thing given the age.

GlenGardner1

I know this is old now, but I am running into the same issue. Was this BUG fixed?

sosero

@ChristopherCounsell @abureaux

We have logged this issue as a bug and our Survey123 team is aware of the issue. Here is the Bug number, and we will wait for it to be addressed: BUG-000171796.

abureaux

Ya, the fact that is isn't every submission is the really strange part.

Probably need to open a case and see if Esri can recreate on their end. I'd try, but I neither have access to Make, nor a FL with that many attachments. Not sure if things have changed, but they always seemed resistant to troubleshooting Make/Integromat in the past. But they own the Make connector, so can help.

ChristopherCounsell

It's not every feature. A handful impacted among hundreds today. No changes
on our side. Latest app etc. so I assume there's similar size object IDs
withour the issue.

It appears this way in the raw json input make receives, and only the
object Id within the attachment url is impacted. It appears normal
elsewhere in the json. The images also get submitted fine...

abureaux

Reddit to the rescue? TLDR that I got was all numbers in JSON are floats, and that scientific notation conversion is integrated into JSON for dealing with large numbers. (How much space can they actually save with that conversion!?)

Can you dump the value into a string variable (Initialize/Set Variable in Power Automate)? It's been so long, I don't remember Make's capabilities.

But that begs the question of at what point does this conversion happen. Is your screen shot of the initial response, or part way through the flow? If it's the initial response, I guess there aren't many options beyond bugging Make/Esri to fix the request 😞

abureaux

I have not seen this in Power Automate yet. I am very interested to know what Esri says.

I think this may be "normal behaviour" for JSON when working with large numbers. Make doesn't seem to be "decompressing" the shortened number properly. Not sure if that would be a Make issue, or an Esri issue. I'm currently leaning to Make, but I'm not an expert on these web requests.

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.