Default autoRestart delay breaking GoldenGate extract

When analyzing a customer’s GoldenGate deployment after a server reboot, I found a weird extract, which reported RUNNING. However, it was not extracting anything at all. Its report files were full of ABENDING entries. Here is a description of the problem, and what could have avoided this.

managedProcessSettings

ADD EXTRACT/ADD REPLICAT over the REST API accepts a managedProcessSettings object. It has two sub-objects, autoStart and autoRestart. The autoStart.enabled flag controls whether the process comes back up when the Administration Server itself starts or restarts. The autoRestart.enabled flag controls whether the process comes back up by itself after abending. Most of the time, you can them set to true. It allows the processes to persist through an abend or a server reboot without anyone taking action.

Here is this setting applied through oggrestapi.py, the GoldenGate REST client I use for this kind of automation :

from oggrestapi import OGGRestAPI

# Direct connection to the Administratin Service
client = OGGRestAPI(url="https://vmogg:7810", username="ogg", password="ogg")

client.create_extract(
    extract="EXT",
    data={
        "config": [
            "EXTRACT EXT",
            "USERIDALIAS source_pdb",
            "EXTTRAIL aa",
            "TABLE hr.*;"
        ],
        "source": "tranlogs",
        "begin": "now",
        "status": "stopped",
        "managedProcessSettings": {
            "autoStart": {"enabled": True},
            "autoRestart": {"enabled": True}
        }
    }
)

Here is the same call with the requests module:

import requests
from requests.auth import HTTPBasicAuth

base = "http://vmogg:7810/services/v2"
auth = HTTPBasicAuth("ogg", "ogg")
headers = {"Accept": "application/json", "Content-Type": "application/json"}

body = {
    "config": [
        "EXTRACT EXT",
        "USERIDALIAS source_pdb",
        "EXTTRAIL aa",
        "TABLE hr.*;"
    ],
    "source": "tranlogs",
    "begin": "now",
    "status": "stopped",
    "managedProcessSettings": {
        "autoStart": {"enabled": True},
        "autoRestart": {"enabled": True}
    }
}

requests.post(
    f"{base}/extracts/EXT",
    auth=auth,
    headers=headers,
    json=body
)

The question I will answer here is: why are default settings dangerous, if they ware accepted by GoldenGate ?

Extract settings returned with GET

If you check the extract after creating it, it shows the rest of managedProcessSettings that GoldenGate filled in by itself :

>>> client.get_extract(extract="EXT")

{
    "$schema": "ogg:extract",
    "begin": "now",
    "encryptionProfile": "LocalWallet",
    "managedProcessSettings": {
        "autoStart": {
            "enabled": true,
            "delay": 0
        },
        "autoRestart": {
            "enabled": true,
            "onSuccess": false,
            "delay": 0,
            "retries": 9,
            "window": 60,
            "disableOnFailure": true,
            "failures": 0
        }
    },
    "targets": [],
    "config": [
        "EXTRACT EXT",
        "USERIDALIAS source_pdb",
        "EXTTRAIL aa",
        "TABLE hr.*;"
    ],
    "source": "tranlogs",
    "type": "Integrated",
    "registration": "none",
    "status": "stopped"
}

With requests, you would get the extract with the following command:

requests.get(
    f"{base}/extracts/EXT",
    auth=auth,
    headers=headers
).json()["response"]

Two values here are the problem: autoRestart.delay is 0, and autoRestart.disableOnFailure is true.

Why delay: 0 is dangerous

autoRestart.delay is the pause GoldenGate takes after a process terminates before it restarts it. With delay: 0, there is no pause at all. Whenever a process abends, it starts again immediately. Whatever caused the abend may still be true a moment later (a bad credential, an unreachable database, a missing trail directory). So most of the time, the extract abends again, and is stuck in a RUNNING loop.

I reproduced this with an extract whose USERIDALIAS points at a non-existing credential. I left autoRestart.delay at the default 0, started the extract, and polled its status every second :

>>> client.start_extract("EXT")
>>> for i in range(20):
...     st = client.get_extract_status(extract="EXT")
...     print(st["status"], st["processId"], st["position"])
...     time.sleep(1)
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
running 4294967295 0.0
stopped None 0.0

In this case, none of the reads returned abended. The report files give the explaination: they all end in the same way:

2026-08-30 11:53:07  ERROR   OGG-00303  [OGG-15409] Alias 'NOSUCHALIAS' not found in credential store domain 'OggAdminDomain'.

2026-08-30 11:53:07  ERROR   OGG-01668  PROCESS ABENDING.

2026-08-30 11:53:20  ERROR   OGG-00303  [OGG-15409] Alias 'NOSUCHALIAS' not found in credential store domain 'OggAdminDomain'.

2026-08-30 11:53:20  ERROR   OGG-01668  PROCESS ABENDING.

Every restart spawns a new OS process, and the process dies again before the next status read hits a live PID. RUNNING and 4294967295 is the basic state retrieved whenever an extract is not working, but in a starting state.

disableOnFailure: true prevents infinite loop

In the example above, the 20th read finally shows stopped, with no error and no explicit stop_extract call. The disableOnFailure setting defaults to true, and retries/window default to 9/60. By default, after 9 abends inside any 60 second window, autoRestart disables itself. A crash loop with delay: 0 burns through 9 retries much quicker. The autoRestart.enabled flag still reports true in a GET, even though it will not fire again.

Fix

You should always give autoRestart a real delay, based on the issues you can expect and tolerate. Turn off disableOnFailure for a process that is meant to keep retrying for as long as the problem lasts. Here is an example of a setting which would repeat indefinitely, but with a longer window between each restart.

"managedProcessSettings": {
    "autoStart": {"enabled": True},
    "autoRestart": {
        "enabled": True,
        "delay": 30,
        "disableOnFailure": False,
        "retries": 9,
        "window": 60
    }
}

If we poll again:

>>> client.start_extract("EXT")
>>> for i in range(15):
...     st = client.get_extract_status(extract="EXT")
...     print(st["status"], st["processId"])
...     time.sleep(1)
running 4294967295
running 4294967295
running 4294967295
running 4294967295
stopped None
stopped None
stopped None
stopped None
stopped None
stopped None
stopped None
stopped None
stopped None
stopped None
stopped None

The process cannot start, because the credential is still missing. But now, it is stopped between attempts, for a longer period. A monitoring check reading status at any point after the first few seconds would spot the issue, as would a human checking the adminclient. With disableOnFailure: false, it keeps trying every 30 seconds instead of giving up after nine failures in one minute.

Summary

• managedProcessSettings.autoStart/autoRestart only need enabled to work. A GET returns a full object with delay, retries, window, and disableOnFailure filled with default values.
• autoRestart.delay defaults to 0. A process abending for a persistent reason (bad credentials, unreachable database) restarts instantly. The REST status endpoint never catches the error. It reads running with the 4294967295 no-PID sentinel instead.
• autoRestart.disableOnFailure defaults to true, with retries: 9 over a window of 60 seconds. A thin crash loop burns through that limit quickly, and after that, the process is stopped with no further attempts.
• Set an explicit delay (30 seconds worked here, but it should be set according to your needs) and disableOnFailure: false on any extract or replicat which should run with minimum downtime.