2.15.0 breaks deserialization when POJO/Record only has a single field and is marked `Access.WRITE_ONLY`

[arlampin]

Describe the bug

Trying to deserialize the following Java Record throws MismatchedInputException

public record Example(@JsonProperty(access = JsonProperty.Access.WRITE_ONLY) String value) {
}

Same issue happens with at least a regular class and @JsonCreator constructor

Adding any other fields fixes the issue, even if those fields are also WRITE_ONLY fields.

Stacktrace:

Cannot construct instance of `foo.bar.baz.Example` (although at least one Creator exists): cannot deserialize from Object value (no delegate- or property-based Creator)
 at [Source: (String)"{"value": "aaa"}"; line: 1, column: 2]
com.fasterxml.jackson.databind.exc.MismatchedInputException: Cannot construct instance of `foo.bar.baz.Example` (although at least one Creator exists): cannot deserialize from Object value (no delegate- or property-based Creator)
 at [Source: (String)"{"value": "aaa"}"; line: 1, column: 2]
	at app//com.fasterxml.jackson.databind.exc.MismatchedInputException.from(MismatchedInputException.java:63)
	at app//com.fasterxml.jackson.databind.DeserializationContext.reportInputMismatch(DeserializationContext.java:1739)
	at app//com.fasterxml.jackson.databind.DeserializationContext.handleMissingInstantiator(DeserializationContext.java:1364)
	at app//com.fasterxml.jackson.databind.deser.BeanDeserializerBase.deserializeFromObjectUsingNonDefault(BeanDeserializerBase.java:1424)
	at app//com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:352)
	at app//com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:185)
	at app//com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323)
	at app//com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:4825)
	at app//com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3772)
	at app//com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:3740)

Version information
2.15.0

To Reproduce
Using the above record definition with plain ObjectMapper throws the above exception

new ObjectMapper().readValue("{\"value\": \"aaa\"}", Example.class);

Expected behavior
With 2.14.2 value was successfully deserialized.

[JooHyukKim]

This one seems to be introduced in issue #3736 by PR #3737.

jackson-databind/src/main/java/com/fasterxml/jackson/databind/introspect/POJOPropertiesCollector.java

Lines 441 to 445 in 8040e2a

	// 15-Jan-2023, tatu: [databind#3736] Let's avoid detecting fields of Records
	// altogether (unless we find a good reason to detect them)
	if (!isRecordType()) {
	_addFields(props); // note: populates _fieldRenameMappings
	}

[yihtserns]

To be fair, this is caused by the combination of #3724 + #3737 (this won't happen if either one is not done, but when together they cause this).

Since I'm partially responsible (for #3724), I'll provide a fix as soon as I can. In the meantime, you can use this workaround if you can/want to:

public record Example(@JsonProperty(access = JsonProperty.Access.WRITE_ONLY) String value) {

    // Force the incorrectly generated intCreator into propsCreator
    @JsonCreator(mode = JsonCreator.Mode.PROPERTIES)
    Example {
    }
}

[yihtserns]

@arlampin out of curiosity, what's the reason for allow a Record (essentially a data/DTO object) field for deserialization but not for serialization?

[arlampin]

@arlampin out of curiosity, what's the reason for allow a Record (essentially a data/DTO object) field for deserialization but not for serialization?

To prevent accidentally logging sensitive data. We could skip storing/logging the whole object in this case, but it's written this way to be consistent with other input classes.

[JooHyukKim]

In case anyone's willing to look into it, I submitted a test case #3899 which might help jump-start digging into it.

[yihtserns]

Created PR #3910 for this.

[yihtserns]

How this scenario ended up in mode=DELEGATING?

How a 1-arg constructor parameter is evaluated (priority according to the listed order):

	What	Properties-based	Delegating
1	Constructor parameter has @JsonProperty("<some name>")	✅
2	Any field has @JsonValue		✅
3	Any getter method has @JsonValue		✅
4	Constructor parameter has @JacksonInject	✅
5	Constructor parameter name matched a getter method name	✅
6	Constructor parameter name matched a field name	✅
7	Default		✅

For deserialization, when a property is annotated with JsonProperty(access = WRITE_ONLY):

• Getter is removed
• Field is not removed

So while it will not hit number 5, it should hit number 6. But because Record fields were removed by #3737, it didn't hit number 6 and ended up with the number 7.