[CORE-20] [Bug] Jobs running on dbt 1.0.0 are failing when setup to defer to a pre 1.0.0 manifest

[GideonShils]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

When a job with defer set is updated from a pre 1.0.0 version of dbt-core to 1.0.0, the job fails with the following error:

Field "metrics" of type Mapping[str, ParsedMetric] is missing in WritableManifest instance-

Expected Behavior

Jobs with defer set should be able to be updated to dbt-core 1.0.0 without error.

Steps To Reproduce

1. Have a job set to 0.21.1 (last pre-release)
2. Enable the defer option to defer to previous manifests of the same job
3. Run the job
4. Upgrade the job to 1.0.0
5. Run the job again

Relevant log output

`Field "metrics" of type Mapping[str, ParsedMetric] is missing in WritableManifest instance`-

Environment

- OS:
- Python:
- dbt:

What database are you using dbt with?

No response

Additional Context

No response

[antongoncharuk]

Having the same issue in dbt cloud, works fine in the CLI.

[jtcohen6]

This is a tricky chicken-and-egg problem. Artifacts are versioned, such that we should be able to compare artifact version and raise a helpful error message:

dbt-core/core/dbt/exceptions.py

Lines 271 to 296 in 3fc715f

	class IncompatibleSchemaException(RuntimeException):
	def __init__(self, expected: str, found: Optional[str]):
	self.expected = expected
	self.found = found
	self.filename = 'input file'
	super().__init__(self.get_message())
	def add_filename(self, filename: str):
	self.filename = filename
	self.msg = self.get_message()
	def get_message(self) -> str:
	found_str = 'nothing'
	if self.found is not None:
	found_str = f'"{self.found}"'
	msg = (
	f'Expected a schema version of "{self.expected}" in '
	f'{self.filename}, but found {found_str}. Are you running with a '
	f'different version of dbt?'
	)
	return msg
	CODE = 10014
	MESSAGE = "Incompatible Schema"

That error message is supposed to be raised in the try/except where we raise this error:

dbt-core/core/dbt/contracts/state.py

Lines 16 to 20 in 3fc715f

	try:
	self.manifest = WritableManifest.read(str(manifest_path))
	except IncompatibleSchemaException as exc:
	exc.add_filename(str(manifest_path))
	raise

Unfortunately, we raise a different error here:

ipdb> self.manifest = WritableManifest.read(str(manifest_path))
*** mashumaro.exceptions.MissingField: Field "metrics" of type Mapping[str, ParsedMetric] is missing in WritableManifest instance

Is there any way we can trip the IncompatibleSchemaException instead?

---

It would definitely be preferable to raise a different error message, one that more clearly indicates the cause of the problem is a version mismatch. The job would still fail, though.

In this particular case, there are things that dbt Cloud could do here to help, such as including dbt version in the deferral candidate logic: the run must be successful and using the same dbt version as the current job definition. That's even more feasible, post-v1, since dbt Cloud will consider all versions 1.0.x to be 1.0 (latest).

There's a desirable future world in which such logic would be too strict, because artifact schema versions aren't changing with each new minor version of dbt-core. That's something we need to build toward.

[ChocoletMousse]

Having the same issue in dbt cloud, works fine in the CLI.

I've also encountered this issue in the CLI when using the state:

[leoebfolsom]

I see a PR is now open! Thank you @gshank and team.

Does this update make it so that I can run

dbt seed --select state:modified+ --full-refresh

without an error?

Or will I still receive an error, but a more descriptive and clear one than Field "metrics" of type Mapping[str, ParsedMetric] is missing in WritableManifest instance?

I am upgrading from 0.21.1 to 1.0.0.

Thank you!

[Update: I ended up modifying my job to avoid the state comparison for the purpose of this upgrade, per this Slack thread.]

[gshank]

Avoiding the state comparison is the right way to go. We can't load a pre-1.0.0 manifest because several of the field definitions have changed, so the "fix" is to give a better error message. Glad that you were able to get around it!