Dave Rawks

As far as I can piece together the timeline from audit logs: 1. unwrap request with token A 2. unwrap response with token B 3. vault reports token A expired...

That's exactly the problem, it seemingly comes from nowhere. I only have the hash of it, but it matches neither the wrapped (A) not unwrapped (B) token hashes

Ok, picked this back up today and Put together the following log which includes addional loglines where unwrap, set and reads occur in consul-template. https://gist.github.com/drawks/44dfb9437bd27f5b09d9064e1c7a95b3 You can see at lines...

Yes, I added my loglines ontop of your latest commit in the branch

Aha! disabling the watcher against the `VaultAgentTokenFile` [here](https://github.com/hashicorp/consul-template/blob/f8ddedf7a8abe9650fd3fbcc02ea67613328a280/watch/watcher.go#L107) results in everything working as expected. I think what is happening is that we make it through the first read/unwrap/renew loop and...

I think the easiest way to prevent attempts at re-unwrapping the token would be to save the `WrappedAccessor` value from the wrapped token file as an attribute of the `vaultClient`...

Your latest commit isn't /quite/ right, since it will still result in the watcher attempting to unwrap the wrapped token, but the unwrap will fail because we've already unwrapped it...

Always sending the token to the unwrap API and then ignoring the error has the potential for causing a lot of audit log noise on the vault server.

:100: this should be moved to an info level log, normal system behavior that doesn't result in any degradation and self heals should not be something we are warned about.

Having been mostly a back seat observer to these types of efforts in the past I'd say the OOO should be something like: 1. tag and cut a new "final"...