Open Chacoon3 opened 1 month ago
umitanuki
commented
1 month ago That's a fair point. @Chacoon3 how is your use case affected by not reporting the status correctly in real time? The market is closed by the time you need them to be inactive, and should be inactive by the next market open, so I just wonder.
Chacoon3
commented
1 month ago That's a fair point. @Chacoon3 how is your use case affected by not reporting the status correctly in real time? The market is closed by the time you need them to be inactive, and should be inactive by the next market open, so I just wonder.
I think you misunderstood the problem. You probably took my meaning as making options inactive when market is closed and active when the market is open, which is not what I mean.
The problem is about the behavior of option contracts that have just expired on the day when the query is made. In other words, if I make a query after 4:15pm on a day to search late-close options that expire on the same day, the endpoints will not return data unless I specify the status to be active, although the options are indeed expired. So this is a bug because late-close options do expire after 4:15pm on their expiration date.
For example, on Sept. 23, 2024, you can reproduce the bug by querying SPY options that expire on Sept. 23, 2024.
An Example Use case:
Users need to conduct back tests. If I want to conduct a option back test after today's market is closed, I can't get option contracts that expired today unless I know this bug. In fact, that was how I found this bug.
Besides, I don't think fixing this bug requires real-time reporting. Most options expire on either 4:15pm or 4pm. So server-side can just change the contracts' activeness right after the time of expiration.
P.S. I would be very appreciative if you could also take a look at another issue I raised at https://github.com/alpacahq/Alpaca-API/issues/261.
Many option data vendors, for instance Polygon, are providing option open interest as a field in their endpoints for option snapshots. Currently I found no Alpaca data API endpoints that provide open interest. Users can get open interest only by querying the trading API endpoints.
Some trading strategies may include option open interest during the process of trading signal generation. So providing open interest in the data API endpoints would be very helpful.
umitanuki
commented
1 month ago I think I understand your report the way you meant. To rephrase it,
Let me know if I still don't understand the issue
Chacoon3
commented
1 month ago I think I understand your report the way you meant. To rephrase it,
- The contract is actively traded at 3pm today, and the API returns it correctly as "active"
- The contract expires and no longer traded at 4:30pm today (the same day). It is currently reporting as "active" at 4:30pm but you want it to be "inactive" because it has expired
Let me know if I still don't understand the issue
Thank you and yes that's what I mean.
Let me know your thought on this issue.
Describe the bug Option contracts that have expired today are still considered "active" and can only be queried by specifying the status parameter to be "active".
For example, let's say today is 2024-09-20 and the time has passed 4:15pm, if I query QQQ options that expire on 2024-09-20 and if I specify the status parameter to be "inactive", no options will be returned. Conversely, the same query with the status parameter being "active" returns QQQ options that expire on 2024-09-20.
Since the options have expired after 4:15pm, there status after 4:15pm should be inactive. So it is the first query that should return data.
To Reproduce On any trading day after 4:15pm, query this url and replace the date with the actual date: 'https://paper-api.alpaca.markets/v2/options/contracts?underlying_symbols=QQQ&expiration_date=2024-09-20'.
This bug can be reproduced by querying other late-close options as well.
Expected behavior For the late-close options, their status should be active before 4:15pm on expiry date and inactive otherwise.
Additional context Single name options, for instance, options of NVDA, appear not to have this bug.