Is there a reason that we don't have a super call here, when we have one in the StreamInput constructor?

you means the constructor only for RequestType?

No the one with both fields

I guess if the super constructor only has the one argument, then the super call should be in the other constructor actually.

For here, I am trying to use constructor overloading. we can define the first constructor is a special case of the second constructor, constructor can uses the this keyword to call another constructor in the same class, and for the first constructor we only need requestType so we set the argument uniqueId as null and only pass requestType.

I looked more into it, and there isn't a constructor on TransportRequest that only uses requestType so we're fine in this case. In general though, even when overloading we can still use a super call if the same method exists in the class that we are extending.

You are right, I will delete the first constructor.

Don't delete it - the overload is necessary here

Everything is good with the constructors on this PR

Nit: these nested if statements could be combined with &

We probably want to remove the super(in) on the stream constructor, then. I think it's a no-op for responses anyway, but I think the two methods should match up.

(Style/Naming) Since this is a list of possibly more than one dependency, would prefer to use the plural dependencies here (and the getter, toString, equals, hashCode, etc.).

(Code smell) This is not a good idea to have a locally scoped loop variable dependency with the same name as the instance variable. If you change the instance variable to dependencies the use of dependency inside the loop will be unambiguous.

@mloufra is correct here, we can't use both super() and this(). We could use super() in the other constructor, but the constructor for the superclass doesn't do anything so it's not needed.

For all the other existing use cases of ExtensionRequest we are asking for information that does not depend on the calling extension. Requiring us to include the uniqueId would add unnecessary bandwidth to the transport request.

This would require changing 3 other request/response use cases. If you want to open a new issue to discuss that, I'm ok with further discussion, but I think in this case making it optional is fine.

I would be open to changing the return type from the getUniqueId() getter from a nullable String to an Optional<String> and handling the null check internally if you think that's a better way of handling it.

Consider avoiding null here by making this:

public Optional<String> getUniqueId() {
    return uniqueId == null ? Optional.empty() : Optional.of(uniqueId);
}

Or, consider handling the readOptionalString(in) similarly to the above and storing the value internally as an Optional<String>, which after looking at the equals() implementation is a better idea.

Since we set uniqueId as Optional<String>, it should be return uniqueId == null ? Optional.empty() : uniqueId;

I agree that storing uniqueId as a possible null creates a requirement to check it elsewhere. If we handle the input stream reading and make it an optional there (instead of null) then we could rely on Java to handle .equals() between two optionals without an extra check.