Application log errors in 3.9

[ArnoldT]

We recently upgraded to 3.9 and are very happy with the new event logging feature of the application log.

However it seems to also log user errors like below.

\

I can see why because every process that returns false is logged now.

We are more interested in the exceptions, so for example when the update record process fails for some reason.

Is there a way to filter out these users errors ? I guess there are errors in ‘return’ with a custom error message.

Because now the application log get clogged. We’re fine with having these errors in the application log but it would be nice if these would be flagged as a user error so we can set a filter.

Also sometimes it seems to log validation errors, for example when I create a new service but do not fill in a claim date and press ok I get this validation error:

But also an entry in the application log:

[e.krijgsman]

Hi Arnold,

I am happy you like the event logging feature. Quite a bit of effort went into it’s development and it is satisfying to see people start using in practice and appreciating it. Naturally, some unforseen scenario’s are then encountered, and with the feedback we get (like this message) we can make it even better!

You are correct that basically every process that returns false is logged. There are a few exceptions, which I think are pretty much what you’d call “user errors”:

• Validation error in CommitRecordAction for a record of a (directly called) (Multiple)SubmitPageProcess: this should prevent logs when the user presses “OK” submit button on a detailspage which results in validation errors for that record.
• Warning from CheckDeleteRecordsAction of a DeleteRecordsProcess: this should prevent logs when user tries to delete a record and gets a warning.
• User cancels deletion of a record after a warning in a DeleteRecordsProcess: this should prevent logs when user tries to delete a record, gets a warning and decides to cancel the deletion.

We could consider to classify more special cases as “user errors” (I am open for it), but it is not so easy to determine what is a “user error” and what isn’t. For example, in your first scenario (a beforeudpate process returning success=false), if the commitrecord was called deep inside some other process, it probably isn’t (I am pretty sure you want it logged then). Only if it was called directly by the user (with a “OK” submit button) I think you could consider it a user error. But even then, it should probably only count as a “user error” if the user has entered an invalid value somewhere (so that he can easily fix it), but probably not if there is some configuration issue (that the user might not be able to (or not know how to) change himself).

Maybe you have some good ideas? I’ll try to think of something myself as well. I understand that things like this can cause the application log to get clogged, so I do want to find some way to filter out all the “uninteresting” logs, but on the other hand, I also want to be a bit cautious in order not to hide the ones that you really would want to have seen.

Regarding flagging process event errors: we do attempt to try to check if an error is “handled”. In that case, we set the severity to “info” instead of “error”. To determine whether something is handled or not, we check if the calling process explicitly checks for the success=false returnvalue and does something different with it than showing the message to the user. We could consider adding more statusses here, and label the ones that are “probably user errors” with a lower status, so you can filter them out, but not have them disappear completely just-in-case.

In your second scenario (sometimes it seems to log validation errors), we do try not to log validation errors (as explained above), but maybe for some reason, that doesn’t work correctly here? The “” value for “Log message” doesn’t give any further clues (probably indicates that some process did return success=false, but did not provide an error returnvalue). Could you also provide the “Log details” for such a log message (an additional panel available from the “more” button). Probably it could give us some insights into why this message was logged.

[ArnoldT]

Hi Erik,

Thanks for your reply!

The errors we consider “user errors” are when a process returns false with a custom error message. These are errors that are foreseen by the programmer.

Its totally fine to log these in the application log, but it would be nice if these kind of errors would get a tag so they can be filtered out and we can focus on unexpected errors/exceptions.

The reason we’d like this is because we are planning to post application log errors to a teams channel that is monitored by IT department, we do not want to post the user errors in that channel.

This is the log for the second scenario (I can replicate this, feel free to give me a call if you need more info).
Error in Novulo.Plugins.RecordTools.Controller.ValidateFieldsAction:

at action ‘validatefieldsaction’ in Anker.ApplicationMaintenance.ServiceViews.ServiceRequestsPage.ServiceRequestPage.ProcessClasses.AddMultipleSubmitPageProcess_ServiceRequestPage_99504

Stacktrace:
at Novulo.Framework.Controller.Action.RunAndShowMessageOnError(Dictionary`2 parameters, TaskHandler taskHandler)
at Novulo.PresentationLayers.Kendo.KendoRequestProcessor.a(KendoInputterResult A_0, String A_1, ParameterGetter2 A_2, KendoOutputter A_3)
at Novulo.PresentationLayers.Kendo.KendoRequestProcessor.c(KendoInputterResult A_0, KendoOutputter A_1)
at Novulo.PresentationLayers.Kendo.KendoRequestProcessor.ProcessRequest(HttpContext context)

validatefieldsaction=fieldvalidationaction:
pagestate=servicerequestsdetailspagestate:load(5)
record=servicerequests:load(29759)
addmultiplesubmitpageprocess_servicerequestpage_99504:
trigger.values=[<servicerequests:load(29759),[<“template”,servicetemplates:load(1)>,<“type”,servicetypes:load(1)>,<“title”,“Schade”>,<“reported_by_contact”,organizations:load(20380)>,<“reported_by_contact_person”,connectioncontacts:getnull()>,<“claim_date”,date:getnull()>,<“initials_crewmember”,“”>,<“firstname_crewmember”,“”>,<“surname_crewmember”,“”>,<“birthdate”,date:getnull()>,<“nationality”,nationalities:getnull()>,<“residence_country”,countries:getnull()>,<“rankgroup”,servicestakeholderroles:load(63)>,<“salaryyearcurrency”,currencies:getnull()>,<“salaryyear”,money:getnull()>,<“customer_reference”,“”>,<“hospitalization”,yesno:load(0)>,<“repatriation”,yesno:load(0)>,<“arrival_in_home_country”,date:getnull()>,<“compensation_until”,date:getnull()>,<“incidentplace”,“”>,<“incidentcountry”,countries:getnull()>,<“vesselname”,“”>,<“legalcase”,yesno:load(0)>,<“pandemic”,pandemic:load(0)>,<“specialconditionsptd”,specialconditionsptd:load(0)>,<“temporarydisability”,yesno:load(0)>,<“fittoworkdate”,date:getnull()>,<“emergency_center”,yesno:load(0)>,<“system”,systems:load(48522)>,<“system_version”,systemversions:getnull()>,<“is_liable”,yesno:load(0)>,<“personal_injury”,yesno:load(0)>,<“affects_bonus_malus”,yesno:load(0)>,<“is_recoverable”,yesno:load(0)>,<“is_expert_needed”,yesno:load(0)>,<“service_cause”,servicecauses:getnull()>,<“status”,servicestatuses:load(2)>,<“assigned_to_contact”,organizations:load(672)>,<“assigned_to_contact_person”,connectioncontacts:load(40927)>,<“reported_at”,datetime:load(“2025-10-28T12:01:00”)>,<“acceptance_template”,acceptancetemplates:load(5)>,<“workflow_template”,workflowconfigurations:load(15)>,<“policy_limit”,money:getnull()>,<“note”,“”>]>]
trigger.page=pages:load(98974,displaytypes:load(“View”),[<“pagestate”,servicerequestsdetailspagestate:load(5)>],)
trigger.overriderecord=true
trigger.record=servicerequests:load(29759)
trigger.records=[servicerequests:load(29759)]
trigger.navigation=navigation:load(“Replace”)
trigger.pagestate=servicerequestsdetailspagestate:load(5)
for_each.pos=1
for_each.done=false
for_each.list=[servicerequests:load(29759)]
for_each.item=servicerequests:load(29759)

[e.krijgsman]

Hi Arnold,

I think I more less understand your intentions with the term “user errors”, but I still have some questions about the definition you give. For example, you could argue that (on some level) every reported error is something that is foreseen by the programmer of the action/process in which the error is detected (for which he will normally provide some custom error message).

I think (correct me if I’m wrong) that you only consider processes defined in the architect that return success=false with a custom error message as “user errors”, but not processes/actions defined in the framework or in plugins. That is a distinction we probably could make, and is something that sounds somewhat reasonable, but it does feel kind of arbitrary to me. I think a better (but also more difficult) way of looking at it is whether the caller of the process is aware that the process might return success=false (and under what conditions) and handles it appropriately. We do attempt to detect something like this (whether the caller checks for success=false) and we set the severity of the log message based on this (error if it isn’t checked by caller, info if it is), but that doesn’t really work if the “caller” is an actual user.

As an aside, with the term “with a custom error” message, you mean that you wouldn’t consider the following situation a “user error”? A proceses that detects that e.g. a commitrecord was unsuccesful and then return success=false with the same errormessage as commitrecord returned.

FYI: we are considering implementing some kind of “application defined rules” for log messages, which can be used to tag or filter log messages, according to the needs of that specific application. So in your specific situation you could then define such a rule to filter out the specific messages you don’t want (or tag the messages you don’t want to post to the teams channel).

Anyway, maybe we can continue this conversation in a (Teams) call sometime. I’ll try to contact you there soon.

Regarding the second scenario, the information you provide is sufficient to understand what is going on here: it is not a “regular” validation error, but a validation error reported by the ValidateFieldsAction in the RecordTools plugin. This also explains the “” log message, since that plugin action doesn’t provide an error-returnvalue (probably it should). In our “few exceptions” (that I mentioned in an earlier reply), this plugin action has not been taken into account, so that explains that the message is logged. Probably we should think of a way to include this situation in the “few exceptions” I think. I will create an SR for this in our backend, but I’m not sure on what timeframe we will get to this point, so maybe in the meantime an alternative could be to use the “application defined rules” mentioned above (if we go that route).