JavaScript code limit of 1024 is useless. It also does NOT run on the integration account

[chillwinston]

Describe the Bug

The Javascript code action requires an integration account. That should remove the "noisy neighbor" issue of the JS code impacting other consumption flows - however it doesn't as the Javascript apparently DOESN'T run on the integration account. It still runs within the same execution framework as the rest of the flow.

Please correctly make the flow run on the integration account that is required for the Javascript action - presumably as it was intended - and remove the exceptionally useless tiny limit of 1024 characters for Javascript as the noisy neighbor problem will be removed with the code running on the integration account.

This is clearly a BUG. Please respond on that basis

Plan Type

Consumption

Steps to Reproduce the Bug or Issue

1. Set up integration account as required.
2. Create a javascript action
3. Write any normal / reasonable sized JS code and hit the tiny and useless limit
4. There is no way to force the code to run properly on the integration account that is required

Workflow JSON

Screenshots or Videos

No response

Additional context

No response

[github-actions]

This issue is stale because it has been open for 45 days with no activity.

[chillwinston]

Microsoft : please respond either with "this is not a bug" or some other response. If there is no response then the assumption is that this is a false limitation and deliberate "non-use" of the integration account. It is a deliberate limitation in order to force customers to use a higher costing app model. Which means, frankly, that the "requirement" for the integration account is a lie (to force a monetary cost) and hence trust in this product (and many others) is eroded. Additionally, the lack of testing of many Microsoft products leads to constant faults and breakages. Frankly, we've stopped reporting them as it is Microsoft's obligation to test its own products, not its customers. So instead, customers should shift to using Docker Compose and for larger environments, Kubernetes. Those technologies are vastly cheaper with other cloud vendors. A 66% savings in cost, better products and easier to manage.

[influential-eliot]

Apologies, @chillwinston, but ... I don't wish this to be the default working functionality.

Asking MS to further restrict things makes life harder for a many of us.

Being able to have 'incidental' use of this is a vital thing for turning around solutions quickly and smartly. If we are then having to give clients more complex work, it ups costs, and reduces basic understanding.

I think that you are not being unreasonable in asking, but perhaps a strongly posited warning about actions/functionality/etc would be a better way for MS to handle this, and still provide basic usability to us at the lower levels.

Would it also be fair to say that utilising an 'in GUI' coded JS Function App could achieve the functionality that you're after whilst also providing disassociation to utilise the function elsewhere?

[chillwinston]

Apologies, @chillwinston, but ... I don't wish this to be the default working functionality.

Asking MS to further restrict things makes life harder for a many of us.

Please point to the 'restriction' that I requested of Microsoft.

Being able to have 'incidental' use of this is a vital thing for turning around solutions quickly and smartly. If we are then having to give clients more complex work, it ups costs, and reduces basic understanding.

Please indicate what "this" is in this context and I can respond.

I think that you are not being unreasonable in asking, but perhaps a strongly posited warning about actions/functionality/etc would be a better way for MS to handle this, and still provide basic usability to us at the lower levels.

Would it also be fair to say that utilising an 'in GUI' coded JS Function App could achieve the functionality that you're after whilst also providing disassociation to utilise the function elsewhere?