Blocks list view fails to render if blockType is null for any block

[sm-Fifteen]

Description

I'm getting a blank "Blocks" page with a TypeError: f is null/TypeError: Cannot destructure property 'name' of 'f' as it is null. when trying to see the blocks I have defined. Unminified, this turns into TypeError: blockType is null/TypeError: Cannot destructure property 'name' of 'blockType' as it is null.. The error is thrown somewhere in @prefecthq/orion-design, in the BlockDocumentsTable component, though the code for that doesn't seem to be public.

The block in question (as returned by /api/block_documents/filter) looks like this:

{
	"0": {
		"id": "43a0a068-4fe5-4352-9dc7-1a93eb46f6fa",
		"created": "2022-07-08T19:09:40.999440+00:00",
		"updated": "2022-07-08T19:09:40.999440+00:00",
		"name": "GitHub Stars-demo-github-stuff-6a9346447d291751502c822090c6b05c-0",
		"data": {
			"storage_path": null
		},
		"block_schema_id": "69692c52-9ea7-4108-aaf3-2f6bfa1aede1",
		"block_schema": {
			"id": "69692c52-9ea7-4108-aaf3-2f6bfa1aede1",
			"created": "2022-07-08T19:08:06.583380+00:00",
			"updated": "2022-07-08T19:09:40.950000+00:00",
			"checksum": "sha256:3a67d4187da98a983d948e042969437dbd14d49854c528a8026cb9a96121ccef",
			"fields": {
				"title": "LocalStorageBlock",
				"description": "Store data in a run's local file system.",
				"type": "object",
				"properties": {
					"storage_path": {
						"title": "Storage Path",
						"type": "string"
					}
				},
				"block_type_name": "Local Storage",
				"block_schema_references": {}
			},
			"block_type_id": "e24caa13-0c2b-4441-8c03-268e53e30ffc",
			"block_type": null,
			"capabilities": [
				"writeable",
				"readable",
				"storage"
			]
		},
		"block_type_id": "e24caa13-0c2b-4441-8c03-268e53e30ffc",
		"block_type": null,
		"block_document_references": {},
		"is_anonymous": false
	}
}

I'm not entirely sure how I ended up with that in my test database (I'm still trying to figure out blocks and this bug is not helping), but according to the route response schema, this is a valid response, and block_type is not a required component of the response (otherwise Pydantic would have caught it).

Reproduction / Example

I don't know how to reproduce the issue end-to-end yet, as I've upgraded Prefect repeatedly from 2.0b6 to b13 in a short time, and I'm wondering whether some data format changes along the way and bad migrations might have created that.

Judging by the name and creation date of the block, this could actually be due to me misusing yaml deployments, as it matches the deployment name and flow name I used when I ran into this other issue.

[sm-Fifteen]

Ah, I see. The local storage blocks only just got removed by e40945d and this schema migration (even though the doc still mentions them), and it would appear like this block_document entry is now pointing towards a non-existent block type (LocalStorageBlock), which still exists in my block_schema table but doesn't have a match in the block_type table anymore. I don't know how likely this is to happen post-release, but I'm guessing that could be an issue for collections that contain block types that subsequently get uninstalled.

Should the UI be able to handle that case or should that field be declared non-nullable in the API?

[zhen0]

Thanks for the detailed write up and the deep questions @sm-Fifteen! We've put a lot of work into blocks migrations to prevent this issue in future but I think we could also look into making the UI able to handle issues like this more robustly. I'm adding a UI label and we can think through how to handle as part of future blocks updates.

[zhen0]

This should now be resolved so closing. Please let us know if you see again!