Correct api.getFluxImages usage

[aaron7]

api.getFluxImages takes 3 parameters: getFluxImages(id, serviceId = null, containerFields = []) with a recent change adding the containerFields parameter.

The 3rd parameter (2) passed to api.getFluxImages has been incorrect for a while now.

Fixes https://github.com/weaveworks/service-ui/issues/2749

[leth]

Sorry, I think that one may have been leftover from some cleanup I did

[bricef]

History

The history of this bug is very interesting.

First, in service-ui

commit 89c94df676a3eba6f9319b66a4c093477c70e32d
Date:   Tue Jul 4 17:13:10 2017 +0200

Adds a third version argument to the getFluxImages function, which remains unused from the scope code.

A little later, in scope

commit 7dcdc8db12d8b2b2f7c8334531c6be5855acac84
Date:   Wed Oct 11 12:41:18 2017 +0200

Actually uses the third argument to pass on version=2 to the function

After some reworking, The API function looses the third argument altogether in April this year

commit 4d4c60615acbd9a86eaf0439026b5ec6853a5c5f
Date:   Tue Apr 10 14:16:08 2018 +0100

The scope code isn't updated, but because javascript don't care, everything works just fine.

A little later, however, the service-ui code gets update to accept a third positional argument again in

commit 28f9cc04f66aeb14f72be92a2cad48e0963dd83e
Date:   Fri Jun 15 16:45:58 2018 +0100

The scope code, unaware, is still using the third positional argument as a version, but the service-ui code now expects an array.

💥BOOM💥

Lessons

1. Don't use javascript, because it's too permissive? 🤷 Arity errors should be a thing godammit.
2. Grep the entire codebase when refactoring service-ui for random snippets that might need updating.
3. Anything else?

[leth]

We could come up with another way to inject weave cloud functionality into scope so that the code which depends on the Weave Cloud UI stays in that codebase

[fbarl]

We could come up with another way to inject weave cloud functionality into scope so that the code which depends on the Weave Cloud UI stays in that codebase

@foot and I had a lot of casual chat recently on how this could be done, maybe it was about time I opened an issue - https://github.com/weaveworks/service-ui/issues/2759 :)

[jml]

The history confuses me. IIUC, the commit that breaks things is from Jun 15. However, the incident did not occur until Jun 20. What explains the discrepancy?

[leth]

Commit 28f9cc04f66aeb14f72be92a2cad48e0963dd83e from June 15th was not merged until the afternoon of Monday June 18th. We locked the UI service on the 18th due to other issues so this may have hit production on the afternoon of the 19th