Firewall Transaction Details | STATUS: FAILED | EVENT : UPDATE "statusmessage": "record exists"

Using Sophos Central Firewall Management to make changes to multiple XGS136 (SFOS 20.0.0 GA-Build222)

The Tasks Queue are failed:
Firewall Transaction Details
ID : 123 | STATUS: FAILED | EVENT : UPDATE
ExampleApplicationFilter (Update app filter policy api)
record exists (503)
{
"response": {
"Entity": "applicationfilterpolicy",
"statusmessage": "record exists",
"status": "503",
"Event": "UPDATE"
}
}

Because the statusmessage is "Record Exists" 
The I have deleted the Application filter: ExampleApplicationFilter

Then I click Retry in Task Queue ID : 123

I get the same FAILED message

When I click: Skip (Ignore this failure) 
The Queue got stuck on the next ID #124 with the same FAILED message.

Is it possible to clear all Task Queues?
Is this a known problem?



Added tags
[edited by: Gladys at 2:18 PM (GMT -8) on 1 Jan 2024]
Parents
  • update1
    I have contacted Sophos support

    He suggested to disconnect the firewall from Sophos Central en reconnect it to have it synchronised.

    The compleet synchronisation took a couple of minutes and finished in the same failed status

    record exists (503)
    {
    "response": {
    "Event": "UPDATE",
    "status": "503",
    "statusmessage": "record exists",
    "Entity": "applicationfilterpolicy"
    }
    }


    Because of new synchronisation this is part of the TASK:

    First ADD and then UPDATE
    What I think is strange that it give no error by ADD filter policy but with UPDATE filter policy
    I expected to fail at ADD filter policy

    {
    "opcodeID": 951,
    "entityID": 552,
    "entityName": "add_app_filter_policy_api",
    "opcodeType": 1,
    "orderID": 1238,
    "opcodeString": "",
    "responseStatus": "{\"status\":\"503\",\"Event\":\"ADD\",\"Entity\":\"applicationfilterpolicy\",\"statusmessage\":\"record exists\"}",
    "uniqueName": "ExampleApplicationFilter apps-552",
    "updateFlag": "f",
    "mainEntity": "t"
    }


    {
    "opcodeID": 948,
    "entityID": 552,
    "entityName": "update_app_filter_policy_api",
    "opcodeType": 1,
    "orderID": 1239,
    "opcodeString": "",
    "responseStatus": "{\"Event\":\"UPDATE\",\"status\":\"503\",\"statusmessage\":\"record exists\",\"Entity\":\"applicationfilterpolicy\"}",
    "uniqueName": "ExampleApplicationFilter apps-552",
    "updateFlag": "t",
    "mainEntity": "t"
    }

  • Hi  ,

    Thank you for reaching out to the Sophos Community forum.

    We understand that you've already connected with Sophos Support. We wanted to follow up if this has been resolved or if further assistance is still needed. If yes, kindly share your Case ID.

    Thank you.

    Gladys Reyes
    Global Community Support Engineer
    Are you a Sophos Partner? | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question, please use the "Verify Answer" button.
    The New Home of Sophos Support Videos!  Visit Sophos Techvids
  • Hi  Gladys,

    this has not been resolved yet.

    Your Sophos global escalation specialists (GES) are working on this Case 07145743

    GES engineers are the highest technical tier within Sophos Support.

    Last contact was 26 december.

    Hope they will follow up soon.

  • Hello there,

    You should have received an email from GES on Dec 29, letting you know that you will receive further feedback within the next 3 business days.

    Let me know if you don't hear from them tomorrow end of the day.

    Regards,


     
    Emmanuel (EmmoSophos)
    Technical Team Lead, Global Community Support
    Sophos Support VideosProduct Documentation  |  @SophosSupport  | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' link.
  • The problem is solved by the GES

    The GES has removed the "applicationfilterpolicy" rule from 4 XGS firewalls

    This is what happened

    --> There was a problem with the XG Firewall application rule name.
    Issue: Unable to update or push appfilter policy from central
    Resolution: We have deleted the problematic rule.

Reply Children
No Data