Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generated types are incorrect when both readOnly and writeOnly are used #453

Closed
bdm-k opened this issue Aug 7, 2023 · 8 comments
Closed

Comments

@bdm-k
Copy link
Contributor

bdm-k commented Aug 7, 2023

Hello,

I'm using version 4.7.4 and I encountered a bug.
Let me take the following schema object for example.

Login:
  type: object
  properties:
    email:
      type: string
      writeOnly: true
    password:
      type: string
      writeOnly: true
    message:
      type: string
      readOnly: true
      description: tells whether the login was successful
  required:
    - email
    - password
    - message

email and password are write-only. message is read-only. None of the properties are used in both read and write. So, the expected generation result is as follows.

export interface Login {}
export interface LoginWrite extends Login {
    email: string;
    password: string;
}
export interface LoginRead extends Login {
    message: string;
}

But the actual result is

export interface Login {
    email: string;
    password: string;
    message: string;
}
export interface LoginWrite extends Login {
    email: string;
    password: string;
}
export interface LoginRead extends Login {
    message: string;
}
@bdm-k
Copy link
Contributor Author

bdm-k commented Aug 7, 2023

This strange behavior is observed only when readOnly and writeOnly are used at once. If I remove the readOnly attribute from message property, the generated interfaces will be

export interface Login {
    message: string;
}
export interface LoginWrite extends Login {
    email: string;
    password: string;
}

email and password are not the member of Login and this is the correct output.

@Xiphe
Copy link
Collaborator

Xiphe commented Aug 8, 2023

Hey @bdm-k that's off... thank you for reporting the issue!

I have an Open PR with quite the big refactor to the read/write only logic

Would you mind giving oazapfts@4.7.4-read-write-fixes.1 a try and see if the problem still persists with that version?

@bdm-k
Copy link
Contributor Author

bdm-k commented Aug 8, 2023

@Xiphe Thank you for taking time to look into this issue.
I gave it a try and the problem still exists.

@Xiphe
Copy link
Collaborator

Xiphe commented Aug 9, 2023

Damn ;)

I'll try to reserve a few hours next week to see if I can address the issue in the linked PR.

@bdm-k
Copy link
Contributor Author

bdm-k commented Aug 14, 2023

// By filtering by readOnly/writeOnly props, we may have filtered out all props in schemas
const hasFilteredAllProps = filteredPropertyNames.length === 0;
const names = hasFilteredAllProps ? propertyNames : filteredPropertyNames;

Hi @Xiphe. It seems like these lines have to do with the problem.

Xiphe added a commit that referenced this issue Aug 14, 2023
the behaviour has been introduced to address #419
but it seems it's not required with the new implementation

fix #453
@Xiphe
Copy link
Collaborator

Xiphe commented Aug 14, 2023

Good catch! Can you give oazapfts@4.8.0-read-write-fixes.2 a try?

@bdm-k
Copy link
Contributor Author

bdm-k commented Aug 14, 2023

The problem has been fixed in that version! Thank you very much!

@Xiphe
Copy link
Collaborator

Xiphe commented Aug 14, 2023

Ok, I'll be on vacation for a good week now. And I'd rather be around for some days after I merge the fix to main. But I'm gonna do that right when I'm back.

@Xiphe Xiphe closed this as completed in 02e9e85 Aug 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants