4. Bug Fixed

Fixed Incorrect Cache Mapping When Sending SKYVVA Cache to the Agent

There is an issue while you have executed the interface and raise an error due to the agent cache of interface get null due to cache table map from salesforce and agent did not reliably handle interface status values from SKYVVA when the JSON field name used different casing or naming styles, such as Status__c, Status_c, status__c, status, or Status. We have fixed this by adding JSON aliases for the interface status field so the Agent can correctly map status values from different SKYVVA payload formats. Now your interface will be executed normally based on the interface status cache map correctly.

Recreate Missing Agent Log Folder/File After Log Deletion

When logs were deleted from the Agent Control Board, the agent-log folder or log file could be removed while the Agent was still running. In this case, the active log stream continued writing to the previous file handle, but the deleted log folder or log file was not recreated on disk. As a result, new log files were not visible until the next log rollover or until the Agent was restarted. This issue has been fixed by adding a rolling file appender that checks whether the target log file exists before each write. If the log file or its parent folder is missing, the appender automatically reopens the file and recreates the missing folder. The new appender has been configured in logback.xml for both system rolling log appenders and per-integration rolling log appenders. After deleting logs from the Agent Control Board, the Agent can now automatically recreate the required log folder and log file without requiring an Agent restart.

Fixed Duplicate Agent Job Creation During Outbound Processing

An issue occurred when a user deleted an Agent job while the Agent was still executing outbound interface processing. Although the job was removed from the Agent cache in the PostgreSQL database, it still remained in the Agent memory until the current outbound execution finished. If the user manually executed the same outbound process again, the Agent created a new job with the same interface object ID but a different job ID. When the first outbound execution finished, the Agent attempted to update the job status. However, because the original job cache had already been deleted from PostgreSQL, the Agent created a new job record again. This caused duplicate jobs with the same object ID. After duplicate jobs were created, the next manual execution could fail because the job query returned more than one record instead of a unique result. This issue has been resolved. If an old job has already been deleted, the Agent will no longer insert it again after the previous execution finishes. The Agent now keeps only the latest executed job, preventing duplicate job records and allowing manual outbound processing to continue normally.

Add Clearer Logs for Manual Processing for Outbound Interface

Manual processing for the outbound interface did not have enough clear log checkpoints to trace the execution flow. It was difficult to identify where the process started, how it moved between routes, and when the outbound logic was executed.

This made troubleshooting manual execution more difficult, especially for synchronous/asynchronous processing, outbound tasks, and Interface, Interface Group, and Integration-level processing.

We added clearer INFO logs around the manual processing flow, including:

Manual processing route execution
Synchronous and asynchronous execution
Outbound task execution
Interface processing
Interface Group processing
Integration processing

Manual processing is now easier to trace in the Agent logs, and normal log output is cleaner and more focused.

Skip Processing When JobProcessDetails Is Not Found in the Database

During job processing, the Agent could continue processing a stale in-memory JobProcessDetails entry even after the related job detail no longer existed in the database. This could happen when the job detail was removed or no longer available, but the Agent still had an old in-memory reference during the processing loop. Additionally, manual process payloads with Instant timestamp values could have serialization or deserialization issues when using Gson. This issue has been fixed by adding a query to verify whether the job detail still exists in the database before processing. If the job detail is not found, the Agent now skips that entry and returns early in the forEach loop instead of continuing to process stale in-memory data. Gson Instant type adapters have also been registered to ensure timestamp values are serialized and deserialized correctly in manual process payloads.