NetworkX GraphML writer and append-mode file handling: ensuring idempotent retries

Direct answer

Use overwrite or a temporary-file-plus-rename pattern — never append mode — for retried write_graphml() calls. Append mode is the wrong tool here: each retry writes a complete, self-contained GraphML document (XML declaration, <graphml> root, all nodes and edges), so appending produces two full documents concatenated in one file. That is not valid GraphML for most parsers, and even lenient readers will see every node and edge twice.

What is confirmed vs. likely

Confirmed behavior: write_graphml() has no idempotence flag and no notion of merging with existing file content. It serializes the whole graph on every call. If you pass a file handle you opened yourself in 'a' or 'ab' mode, the duplication is on the caller, not the library.

Likely explanation for unstable diffs: attribute ordering in the emitted XML depends on dictionary/attribute iteration order, which can vary across NetworkX releases (and historically across Python versions). So byte-level diffing between two writes of the same graph is not a reliable correctness check. Treat this as a property of the serializer, not a bug you can configure away.

Recommended retry-safe pattern

Write to a temporary file in the same directory, then atomically rename over the target:

import os, tempfile
import networkx as nx

def write_graphml_idempotent(G, path):
    dir_ = os.path.dirname(os.path.abspath(path))
    fd, tmp = tempfile.mkstemp(dir=dir_, suffix=".graphml")
    os.close(fd)
    try:
        nx.write_graphml(G, tmp)
        os.replace(tmp, path)  # atomic on POSIX; same-volume required
    except BaseException:
        os.unlink(tmp)
        raise

Key points:

• os.replace() overwrites the destination atomically on the same filesystem, so a retry either leaves the old file or the new one — never a partial or duplicated file.
• The temp file must live in the same directory as the target, otherwise the rename may cross filesystem boundaries and fail or degrade to a copy.
• On some network mounts (NFS, certain FUSE filesystems) rename atomicity is weaker; if that applies to you, verify on your actual storage.

On the design questions

• Attribute order preservation: nice for diffing, but not something to depend on for correctness. If you need deterministic output, canonicalize after writing (e.g., parse and re-emit with sorted keys) rather than expecting the writer to stabilize.
• Overwrite as default retry strategy: acceptable and simplest when nothing else modifies the file between attempts. The caveat: overwrite discards any external modification made after the first write.
• Temp-file-plus-rename: yes, this is the right recommended pattern and needs no change to NetworkX itself — it is purely caller-side.

Verification

# After a simulated double-write retry, confirm exactly one document:
grep -c '<graphml' output.graphml   # must be 1
# Or checksum before/after a retry:
md5sum output.graphml

Version assumption: behavior described applies to NetworkX 2.x/3.x; confirm attribute ordering empirically on your installed version if diff stability matters to you.