Propagate failure to detect `MountInfo`

[smurf667]

This request concerns the 3.2.0 release.

While debugging an issue related to Vault access (we're using HashiCorp Vault with a custom authentication mechanism), we encountered a situation where authentication requests occasionally timed out due to a five-second timeout setting in a client.

We discovered that these timeouts were silently caught in the following code block, with logging only at debug level (which was not active):

spring-vault/spring-vault-core/src/main/java/org/springframework/vault/core/util/KeyValueDelegate.java

Lines 135 to 148 in 15c42fc

	catch (VaultException e) {
	if (logger.isDebugEnabled()) {
	logger.debug("Unable to determine mount information for [%s]. Returning unavailable MountInfo: %s"
	.formatted(path, e.getMessage()), e);
	}
	return MountInfo.unavailable();
	}
	catch (RuntimeException e) {
	if (logger.isDebugEnabled()) {
	logger.debug("Unable to determine mount information for [%s]. Caching unavailable MountInfo: %s"
	.formatted(path, e.getMessage()), e);
	}
	mountInfo = MountInfo.unavailable();
	}

As a result, mount information was unavailable, but the code continued attempting to access secrets, which led to "403 Forbidden" errors. It was not immediately clear that the root cause of these access errors was the failure to retrieve mount metadata.

Suggestion: It would be very helpful if such failures were logged at the error or warning level. This would significantly reduce the time required to diagnose similar issues in the future.

Thank you for your work on this project and for considering this request!

[mp911de]

Thanks for reaching out. We introduced mount detection rather late and didn't want to break access in case permissions do not allow access to the sys paths. I'm fine with changing the logger level for the 3.2.x development line and I'm considering to remove the exception handling entirely to see how many users would be affected from the change to remove any obstacles for debugging.

[mp911de]

FTR, Vault responds with a 403 if the mount path is unknown. Since we can create property sources for absent paths, we don't want to fill the entire log with warnings, so we would leniently fall back on 403's to MountInfo.unavailable() with debug logging.