I have a form where people can enter a value between zero and one.  I am using the following element to capture their input

<lightning:input name="example" label="example" type="number" min="0.0" max="1.0" step="0.01"/>

Negative values, being less than the minimum, should not be valid.  Entering "-0.01" is correctly identified as an invalid value.

However, if I instead enter that value as "-.01" (without the zero to the left of the decimal point), the input element does NOT identify it as an invalid value. 

I had to write extra code to check the value before the form gets submitted to compensate for this.

Is this a bug, or is there a configuration that I am missing?
 

I am getting an exception on step 9 of the Data Integration Specialist superbadge. It reads:
We encountered an unexpected error. Try again later, or contact your administrator, who can verify the external data source settings and the external system's availability. Error received from the external system:

There is no other text, the error received seems to be an empty string.
Checking the challenge produces this in my debug logs:


Who would be the administrator to contact for this?

When the lightning component framework batches together multiple actions, should they execute in the same context and consume the same governor limits?  Do they count as a single transaction?

I have a situation where multiple updates are being made separately, and these requests are being batched.  The updates are all to the same object type, but the records arent being collected into a list for the flows and triggers.  So even though we have bulkified triggers, there is a different trigger execution for each update.  That would usually be okay since a list of one record going through a trigger shouldn't exceed any limits.  The problem is that all these triggers are in the same execution context, and have to share the limits they would otherwise have to themselves with several other triggers.

Since they share the same limits, I would think they were the same transaction, but an entire transaction should be rolled back if any part of it fails.  What I'm seeing is that the updates succeed and are committed up until one of them passes a limit.  That update and the ones after it all fail, but the ones that succeeded aren't rolled back.  This feels like a bug.

Without rewriting the components to send those individual updates as one list update, how can I avoid hitting limits?  

I had asked this question on stack exchange already. I took the suggestion to make the requests send in the background.  It works for now, but I know that isn't behavior I can depend on.

I have a form where people can enter a value between zero and one.  I am using the following element to capture their input

<lightning:input name="example" label="example" type="number" min="0.0" max="1.0" step="0.01"/>

Negative values, being less than the minimum, should not be valid.  Entering "-0.01" is correctly identified as an invalid value.

However, if I instead enter that value as "-.01" (without the zero to the left of the decimal point), the input element does NOT identify it as an invalid value. 

I had to write extra code to check the value before the form gets submitted to compensate for this.

Is this a bug, or is there a configuration that I am missing?
 

I am getting an exception on step 9 of the Data Integration Specialist superbadge. It reads:
We encountered an unexpected error. Try again later, or contact your administrator, who can verify the external data source settings and the external system's availability. Error received from the external system:

There is no other text, the error received seems to be an empty string.
Checking the challenge produces this in my debug logs:


Who would be the administrator to contact for this?

When the lightning component framework batches together multiple actions, should they execute in the same context and consume the same governor limits?  Do they count as a single transaction?

I have a situation where multiple updates are being made separately, and these requests are being batched.  The updates are all to the same object type, but the records arent being collected into a list for the flows and triggers.  So even though we have bulkified triggers, there is a different trigger execution for each update.  That would usually be okay since a list of one record going through a trigger shouldn't exceed any limits.  The problem is that all these triggers are in the same execution context, and have to share the limits they would otherwise have to themselves with several other triggers.

Since they share the same limits, I would think they were the same transaction, but an entire transaction should be rolled back if any part of it fails.  What I'm seeing is that the updates succeed and are committed up until one of them passes a limit.  That update and the ones after it all fail, but the ones that succeeded aren't rolled back.  This feels like a bug.

Without rewriting the components to send those individual updates as one list update, how can I avoid hitting limits?  

I had asked this question on stack exchange already. I took the suggestion to make the requests send in the background.  It works for now, but I know that isn't behavior I can depend on.