Extensions don't stay enabled

[jim-docker]

Describe the bug
If you enable an extension then restart Lens, the extension is disabled.

To Reproduce
Steps to reproduce the behavior:

1. Enable an extension (tried @jakolehm/lens-extension-gke-sync and @nevalla/kube-resource-map)
2. Verify it works
3. Restart Lens
4. Observe that the extension is disabled

Environment (please complete the following information):

• Lens Version: 2023.5.251645-alpha
• OS: Linux (AppImage), MacOS

[jim-docker]

If the lens-extensions.json file looks like this before starting Lens:

{
	"__internal__": {
		"migrations": {
			"version": "1.0.0"
		}
	},
	"extensions": [
		[
			"/home/jim/.config/OpenLensDev/node_modules/@andrea-falco/lens-multi-pod-logs/package.json",
			{
				"enabled": true,
				"name": "@andrea-falco/lens-multi-pod-logs"
			}
		]
	]
}

It looks like this right after Lens has started:

{
	"__internal__": {
		"migrations": {
			"version": "1.0.0"
		}
	},
	"extensions": [
		[
			"0",
			[
				"/home/jim/.config/OpenLensDev/node_modules/@andrea-falco/lens-multi-pod-logs/package.json",
				{
					"enabled": true,
					"name": "@andrea-falco/lens-multi-pod-logs"
				}
			]
		],
		[
			"/home/jim/.config/OpenLensDev/node_modules/@andrea-falco/lens-multi-pod-logs/package.json",
			{
				"enabled": false,
				"name": "@andrea-falco/lens-multi-pod-logs"
			}
		]
	]
}

This would explain why the extension is not enabled after restarting Lens. I have seen this before, do you remember what the problem is @Nokel81 ?

[Nokel81]

Looks likes a call to .entries() are being serialized instead or something.

Maybe making a unit test with that initial state and expecting that after the application starts up that the state is the same could help here.

[jim-docker]

@Nokel81 I think this is the culprit. Is this migration just to catch when extensions is not an object? If it is an array we probably should do nothing(?)

[Nokel81]

Yeah we probably should do nothing in that case.

IIRC the shape of the stored object changed in that PR.

Also, does the __migration__ key really not change the version before and after?

[jim-docker]

Also, does the migration key really not change the version before and after?

It does change. That was copy-paste chicanery on my part, I edited my lens-extensions.json file to have just one extension in it, missed the version change.

[Nokel81]

Okay good

[Nokel81]

I believe that the intended behaviour was to convert between an object based storage and an entry based one since the backing type changed from observable.object() to observable.array().

[jim-docker]

Ok. I'm going to double check this because I see the migration version changing for a dev run but it appears the alphas are not changing it(?) On my windows machine, latest alpha, after testing with it and previous alpha:

{
	"__internal__": {
		"migrations": {
			"version": "1.0.0"
		}
	},
	"extensions": [
		[
			"0",
			[
				"0",
				[
					"0",
					[
						"0",
						[
							"0",
							[
								"0",
								[
									"0",
									[
										"0",
										[
											"0",
											[
												"0",
												[
													"0",
													[
														"C:\\Users\\jiim\\AppData\\Roaming\\Lens\\node_modules\\cloud-provider-sync-extension\\package.json",
														{
															"enabled": false,
															"name": "cloud-provider-sync-extension"
														}
													]
												]
											]
										]
									]
								]
							]
						]
					]
				]
			]
		],
		[
			"1",
			[
				"1",
				[
					"1",
					[
						"1",
						[
							"1",
							[
								"1",
								[
									"1",
									[
										"1",
										[
											"1",
											[
												"1",
												[
													"1",
													[
														"C:\\Users\\jiim\\AppData\\Roaming\\Lens\\node_modules\\lens-certificate-info\\package.json",
														{
															"enabled": false,
															"name": "lens-certificate-info"
														}
													]
												]
											]
										]
									]
								]
							]
						]
					]
				]
			]
		],
.
.
.

[jim-docker]

Maybe this is caused by me going from latest to alpha to latest...

[jim-docker]

Hmmm

Screen.Recording.2023-05-29.at.5.37.42.PM.mov

[Nokel81]

Oh I see, that is the single store the now uses a new method of calculating the store version number, which is based on the declared migrations.

But migrations are only declared on main so I guess it defaults to the version of 1.0.0 on renderer. I think the proper fix would be to not read from the file system at all on renderer and instead retrieve the initial state from main.