Conversation
…) and that the signature of the service matches. If not options of overloads are listed.
| allFields | ||
| .stream() | ||
| .filter(ObjectField::isGenerated) | ||
| .filter(ObjectField::hasServiceReference) |
There was a problem hiding this comment.
ser at disse fire linjene er duplisert 4 ganger. Kanskje innføre en hjelpemetode som returnrerer streamen?
| validateRecordParameterTypes(field, serviceWrapper, method, parser, resolverKeyOffset); | ||
| } | ||
|
|
||
| private boolean hasParameterCountMismatch(ObjectField field, CodeReferenceWrapper serviceWrapper, |
There was a problem hiding this comment.
Claude fant en feil som jeg ikke så:
Validerings-gap ved overloads med riktig antall, men feil type
Gitt en service med:
public String checkOverload(String wrongType) { ... }// 1 param, feil type
public String checkOverload(CustomerRecord a, AddressRecord b) { ... }// 2 paramsOg et skjema som forventer 1 CustomerRecord-parameter — ingen av overloadene er gyldige, men valideringen slipper det gjennom.
Årsaken er todelt:
- hasParameterCountMismatch() hopper over type-sjekk når primærmetoden har feil antall, selv om overloaden med riktig antall har inkompatibel type.
- validateRecordParameterTypes() sjekker type mot alle overloads uten å filtrere på parameterantall, så en overload med feil antall men riktig type på indeksen passerer.
Det ser ut til å stemme at dette blir feil
There was a problem hiding this comment.
Her er forslaget den har til fiks
I stedet for den nåværende to-stegs-tilnærmingen (hasParameterCountMismatch → validateRecordParameterTypes), filtrer overloads til de med riktig antall parametere først, og sjekk deretter typer kun mot det
subsettet. Dette fikser overload-buggen og forenkler flyten:
private void checkServiceParameterTypes(ObjectField field) {
> var serviceWrapper = field.getExternalMethod();
> var overloads = getAllOverloads(serviceWrapper);
> if (overloads.isEmpty()) return;
>
> var parser = new InputParser(field, schema);
> var resolverKeyOffset = field.isRootField() ? 0 : 1;
> var expectedCount = resolverKeyOffset + parser.getMethodInputNames(true, true, true).size();
>
> var candidates = overloads.stream()
> .filter(m -> m.getParameterTypes().length == expectedCount)
> .toList();
>
> if (candidates.isEmpty()) {
> addErrorMessage("...count mismatch...", ...);
> return;
> }
>
> // Type-sjekk kun mot kandidater med riktig antall parametere
> for (var entry : parser.getRecords().entrySet()) {
> // ...sjekk mot candidates...
> }
> }
Dette fjerner hasParameterCountMismatch helt og fjerner avhengigheten til serviceWrapper.getMethod() som "primærmetode" — den er vilkårlig (findFirst()-rekkefølge). Ved å filtrere på antall parametere først,
unngår man at en overload med feil antall men riktig type på en gitt indeks slipper gjennom.
| private String formatOverloads(List<Method> overloads, String methodName) { | ||
| if (overloads.isEmpty()) { | ||
| return " (no overloads found)"; | ||
| } | ||
| return overloads.stream() | ||
| .map(m -> " " + formatMethodSignature(m, methodName)) | ||
| .collect(Collectors.joining("\n")); | ||
| } | ||
|
|
||
| private String formatMethodSignature(Method method, String methodName) { | ||
| var params = Arrays.stream(method.getGenericParameterTypes()) | ||
| .map(this::formatTypeName) | ||
| .collect(Collectors.joining(", ")); | ||
| return methodName + "(" + params + ")"; | ||
| } | ||
|
|
||
| private String formatTypeName(Type type) { | ||
| if (type instanceof ParameterizedType pt) { | ||
| var raw = ((Class<?>) pt.getRawType()).getSimpleName(); | ||
| var args = Arrays.stream(pt.getActualTypeArguments()) | ||
| .map(this::formatTypeName) | ||
| .collect(Collectors.joining(", ")); | ||
| return raw + "<" + args + ">"; | ||
| } | ||
| if (type instanceof Class<?> cls) { | ||
| return cls.getSimpleName(); | ||
| } | ||
| return type.getTypeName(); |
There was a problem hiding this comment.
kanskje flytte disse 3 metodene og formatExpectedType som har med tekstformatering til en egen klasse?
ProcessedDefinitionsValidator begynner å bli i største laget, så vi bør se på måter å splitte den litt på.
2 participants
Fixed validation for service inputs (they need either table or record) and that the signature of the service matches. If not options of overloads are listed.