Helm (tiller) might try to upgrade two revisions at the same time

[balboah]

I'm creating a new issue out of comments from #3275 as this looks like a bug and not a support/question. Feel free to close this one if its invalid!

After trying to apply a small configmap value change and upgrading with:
helm upgrade --install -f values-control.yaml control .
I'm getting UPGRADE FAILED: no Secret with the name "foobar" found.

I deleted this secret and re-ran the upgrade which then caused errors on some configmap instead, deleting the configmap and doing a 3rd run once again complained on the previous secret.

Looking at tiller logs I'm seeing

[storage] 2018/02/15 10:20:50 updating release "control.v136"
[storage] 2018/02/15 10:20:50 updating release "control.v226"

It seems that tiller tries to apply the change to two revisions of one release at the same time?
helm ls confirms that there is only one release:

NAME   	REVISION	UPDATED                 	STATUS	CHART                     	NAMESPACE
control	226     	Thu Feb 15 11:20:50 2018	FAILED	foo-0.1.0	default

Trying to list history of this release causes grpc errors (related to #3512 and #3322):

helm history control
Error: grpc: trying to send message larger than max (49338925 vs. 20971520)

This might have been triggered after upgrading from helm 2.7.x to 2.8.1 but I'm not sure as this particular cluster have been idle for some time since after the upgrade.

---

Client: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.8.1", GitCommit:"6af75a8fd72e2aa18a2b278cfe5c7a1c5feca7f2", GitTreeState:"clean"}

[balboah]

Maybe the double release log is normal as,

s.recordRelease(originalRelease, true)
s.recordRelease(updatedRelease, true)

is called on failures. But it seems like a long way between the numbers?
I'm not sure what is causing the missing metadata errors

[balboah]

the newest revision that has status DEPLOYED is 222. When checking helm status --revision 136 that one also has status DEPLOYED. 134 and 136 has SUPERSEDED. Could the bug be about tiller storage failing to change the status of one of the revisions causing it to conflict with itself?

Also after applying #3514 and finding out about --max argument, I can list up to about 60 revisions in helm history. Anything larger than 60 revisions will get the error grpc: trying to send message larger than max (21451805 vs. 20971520).
Which also makes me wonder if the amount of bytes (20MB) to display the history list is another bug as well?

[balboah]

manually editing the configmap to change DEPLOYED to SUPERSEDED in
kubectl -n kube-system edit configmap control.v136 makes the upgrade work again.

[balboah]

Maybe same issue as #2941 except in this case, helm list only has one entry

[bacongobbler]

closed via #3539