Timestamp conversion error in iterations

Hello,

I'm making a WebRequest project to reload our Qlik Sense applications.
But I have an error on my timestamp conversion while doing an iteration (iterate or repeat), and I don't find why.
When the application start the reload process, I send a webrequest to EasyMorph with the current timestamp from java in parameter :
Math.floor(Date.now()/1000);

The goal is to take this timestamp, to compare with the last reloading date of the Qlik Sense application, to notify the user when the application is reloaded.

When I take the result, for example 1750148710 :
In my module, everything works.
I take my parameters : Application ID and the timestamp, all from the webrequest

Then, I do a webrequest to Qlik Sense to have the application informations with the last reload time, and I do an Inner Join with my parameter table on my application ID.
I take this last reload time, convert it to local time (2 hours difference).
I take my parameter ReloadTime, and convert it to a valid timestamp, to compare it with the last reload time.


At the end I'm doing a filter on condition lastReloadTime>=ReloadTime.
Everything here works, even the filter :


Without format, it seems to returns good values :
image

But when using a repeat (same with a simple iterate) I have this :

It's as if the conversion is not done, or the filter does not take into account the format of my parameter.
I tried multiple things, I can't make it works.
There is the debug log after an execution :

20250617 10:42:38 [ERR] [UI] Run completed with 2 errors
20250617 10:42:38 [ERR] [UI] Error: Condition must evaluate to either TRUE or FALSE. However in row #1 it's: #Reference to error in column [ReloadTime].
Source: action "Filter by condition", module "GET APP RELOAD TIME", table "Get All Qlik APP (last reload time à heure -2, besoin de modifier le timestamp)"

[0] Exception message: Condition must evaluate to either TRUE or FALSE. However in row #1 it's: #Reference to error in column [ReloadTime].
[0] Exception type: Exception
[0] Exception source: FSharp.Core
[0] Exception stack trace: at Microsoft.FSharp.Core.PrintfModule.PrintFormatToStringThenFail@1448.Invoke(String message)
at Morph.DataServices.DatasetModule.Filter@301-1.Invoke(Int32 )
at Microsoft.FSharp.Collections.ArrayModule.Parallel.Initialize@2540-1.Invoke(Int32 i) in D:\a_work\1\s\src\FSharp.Core\array.fs:line 2540
at System.Threading.Tasks.Parallel.<>c__DisplayClass17_0`1.b__1()
at System.Threading.Tasks.Task.InnerInvokeWithArg(Task childTask)
at System.Threading.Tasks.Task.<>c__DisplayClass176_0.b__0(Object )
[0] Inner exception is empty
20250617 10:42:38 [ERR] [UI] Error: Iteration of module "GET APP RELOAD TIME" failed.
Source: action "Repeat", module "Main", table "Reception WebRequest"

Called module: module "GET APP RELOAD TIME"
Overridden parameters:
{TargetAPP} = 7adeca4d-89bd-4aa3-9ad5-ab44dba90ba7
{ReloadTime} = 1750148710

Can you help me, or explain me what's wrong ?
Thank you

The error "Reference to error in column [ReloadTime]" means that an expression referenced column [ReloadTime], but the column contained an error, which led to an error in the expression evaluation.

For instance, if I calculate

[C] = [A] + [B]

And column [B] contains an error, then column [C] will also contain an error "Reference to error in column [B]". This mechanism is called error propagation - if an expression (or condition) refers to an error, the result will also be an error.

Exclusions from error propagation

Type-checking functions do not propagate errors. For instance, these functions work correctly, even when the 1st argument is an error value:

iferror()
iserror()

A condition must always evaluate to only either TRUE or FALSE. If a condition is evaluated to something else, in your case it's an error, then it will fail with the error shown in your screenshot.

Trace back how the [ReloadTime] column is calculated before the "Filter by condition" action, and try to find the error value in row #1 to understand what caused it.

1 Like

Also, be careful with timestamp equality. Usually, it's a bad idea to check for equality ("=") of two timestamps, especially if one of them came from an external application, because timestamps in EasyMorph, and, for instance, in Java, are represented differently. Therefore, some precision can be lost when converting from one timestamp to another.

Use only comparisons without equality, if possible. For instance, ">" (greater than) instead of ">=" (greater than or equals to).

If you do need to check timestamps for equality, at least round them up to a millisecond (1/1000th of a second). Keep in mind that rounding in EasyMorph and external applications can be done differently, as there are different rounding algorithms (search the web for "banker's rounding", for instance). Therefore, ensure that the same rounding algorithm is applied to both compared timestamps.

1 Like

Ok, I replaced the greater than or equal by a greater than.

In the module, the expression I use is : localtime(fromunixtime([ReloadTime]))
When doing this : iferror(fromunixtime([ReloadTime]), 'error')
It works great inside the module, but it returns 'error' from the Repeat action.

Is the fromunixtime() function broke used in an iteration ?
I think can't have more details.

@dgudkov I have find the problem, it is really simple.

When using parameters inside a module, for example my parameter "1750145273".
It will be interpreted as a number.

When using call actions from an other module to call a module, the parameter type is the type of the parent field. Even if I put a number like "1750145273" in parameter, if the field is a text, the parameter will be interpreted as a text.

My field is coming from a JSON from a webrequest, so all my fields are text.
The solution is to convert the data from text to number, before assigning parameters, or just before using expressions.

The automatic interpretation of the parameter while doing manual tests get the better of me.
I'm using EasyMorph every days, I discover little things like that everywhere !

Thank you for your help.

1 Like

No, that's impossible.

Try saving the dataset right before the "Filter by condition" action. In this case, when the action fails, you will be able to see what the dataset looked like exactly and understand why the condition failed to calculate in row #1.

That explains it, indeed. Thank you for posting the solution.

1 Like