Introduction

This TensorFlow error comes from TensorFlow 1.x graph execution semantics: a tensor belongs to exactly one graph, and a session can execute only the graph it was created for. If you build a tensor in one graph and try to evaluate it in a session tied to another graph, TensorFlow stops with a graph mismatch error.

Why the Graph and Session Must Match

In TensorFlow 1.x, operations are not executed immediately. You first build a computation graph, then run parts of it inside a Session. Every tensor and operation is attached to the graph that was active when it was created.

The error appears when code mixes those pieces incorrectly. A typical bad pattern looks like this:

1import tensorflow as tf
2
3g1 = tf.Graph()
4g2 = tf.Graph()
5
6with g1.as_default():
7    x = tf.constant(10)
8
9with tf.compat.v1.Session(graph=g2) as sess:
10    print(sess.run(x))

x belongs to g1, but the session is executing g2, so TensorFlow rejects the call.

The Correct Pattern in TensorFlow 1.x

The fix is to create the tensors and the session against the same graph:

1import tensorflow as tf
2
3graph = tf.Graph()
4
5with graph.as_default():
6    x = tf.constant(10)
7    y = tf.constant(32)
8    z = x + y
9
10with tf.compat.v1.Session(graph=graph) as sess:
11    print(sess.run(z))

The important rule is consistency. If a graph is explicit, keep all related ops, placeholders, variables, and sessions inside that graph's context.

This also matters when loading saved models or imported graphs. If you restore tensors into a custom graph, the session you use afterward must point at that same graph instance.

Common Sources of the Mismatch

One source is mixing the default graph with manually created graphs. Code may define a tensor inside with graph.as_default(): and then later open a plain session without passing graph=graph.

Another source is notebooks. Re-running cells can create new default graphs while old tensor objects still exist in memory. The code looks almost identical, but those tensors may belong to a stale graph from an earlier cell execution.

Model-loading code can trigger the same issue. For example, if one helper restores a graph and returns a tensor while another helper creates a different session, evaluation will fail even though both helpers work fine on their own.

A Safer Structure for Legacy TensorFlow Code

If you still maintain TensorFlow 1-style code, keep graph construction and session execution close together. A small helper can make that explicit:

1import tensorflow as tf
2
3def build_graph():
4    graph = tf.Graph()
5    with graph.as_default():
6        a = tf.compat.v1.placeholder(tf.float32, name="a")
7        b = tf.compat.v1.placeholder(tf.float32, name="b")
8        result = a + b
9    return graph, a, b, result
10
11graph, a, b, result = build_graph()
12
13with tf.compat.v1.Session(graph=graph) as sess:
14    value = sess.run(result, feed_dict={a: 2.5, b: 3.5})
15    print(value)

Returning the graph along with the tensors makes the ownership relationship obvious and reduces the chance of running them in the wrong session later.

The TensorFlow 2 Perspective

In TensorFlow 2, eager execution is the default, so most code no longer uses sessions directly. That eliminates this entire class of error for ordinary tensor operations:

1import tensorflow as tf
2
3x = tf.constant(10)
4y = tf.constant(32)
5print((x + y).numpy())

If you are migrating code, the cleanest long-term fix is often to remove explicit session logic altogether. Keep tf.compat.v1.Session only when you are maintaining legacy graphs that cannot be rewritten yet.

Common Pitfalls

The most common mistake is creating a graph explicitly and then forgetting to pass it into the session. If the graph is not the default one at execution time, TensorFlow will treat the tensor and the session as unrelated.

Another pitfall is keeping tensor objects alive across notebook restarts or repeated cell execution. A tensor from a previous run may still exist, but its graph may no longer match the session created in the current run.

It is also easy to mix TensorFlow 1 and TensorFlow 2 styles accidentally. If you are already on eager execution, avoid introducing sessions unless a legacy API forces you to.

Summary

• In TensorFlow 1.x, every tensor belongs to a specific graph.
• A session can evaluate only tensors from the graph it was created for.
• Build tensors and open sessions against the same graph object.
• Notebook re-execution and mixed helper functions often cause graph mismatches.
• In TensorFlow 2, eager execution usually removes the need for sessions entirely.