update_historical_prices bug? #899
-
|
For the past few month that I've been using pysystemtrade, I've noticed that I keep getting multiple, repeat requests for ALUMINIUM contracts in the logs. I assume it's because it's the first instrument alphabetically. I usually see it when I look at the run_daily_historical_prices,log file. I'm not sure what would be causing it. A bug in my config somewhere or something in the code? Here is another snippet from the log file |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
|
"I've noticed that I keep getting multiple, repeat requests for ALUMINIUM contracts in the logs." Flippant answer: This is part of my master plan to persuade Americans that they are spelling the name of this particular metal incorrectly, Real answer: I know thats what it looks like, but that's not what is going on here. Take this line for example:
That clearly isn't alumnium it's trying to get! So the code is operating correctly, but the logging attributes To understand this you need to (re) read the docs around how log objects work: https://github.com/robcarver17/pysystemtrade/blob/master/docs/backtesting.md#logging ... and (b) understand how error handing in ib insync works. Basically log attributes are added to log objects which then maintain these as internal state. These are then overwritten or added to when the log object is passed around. So when we get a load of prices, we'd start with the first aluminimum contract, and the log object would have Subsequently when we sample something else, these attributes are replaced. You can see this here:
Now the attributes reflect what we're actually trading. When logging is called normally from my code, this will always be the case (unless I've forgotten to update the logging object of courrse). But that doesn't explain why some of the logs have aluminimum attributes attached to them. Whats happening here is that the very first time we go to IB, the log object that is passed (which will initially have aluminium in it) is effectively copied, and thus further updates to the original log object have no effect. When an error (or warning) message is called from here it uses that 'frozen' log object to create the log, which still has aluminium in it. That's whats happening, so what can we do about it. The big problem is that the error arrives out of the ether, and there is no way to identify which specific method caused it, and hence what the correct attributres for the error are. Sometimes it has a contract object attached to it, but this is with IB contract labelling not mine, so would require a reverse lookup to see which instrument it relates to. This would fix the 'missing data' type logs which are very common in this snippet. But there is not always a contract object attached, and though when you see the errors printed in the log file it's mostly obvious what the error relates to, to actually write code to do that is somewhat complex. I see the following:
Of these options the second and third are probably the most palatable, so I will raise an issue to do this at some point. |
Beta Was this translation helpful? Give feedback.
-
|
That makes sense. Thanks for explaining it. I admit I have not examined the log object closely. Not as exciting as the other objects I guess! I can ignore the entries easier now that I know what is causing them. |
Beta Was this translation helpful? Give feedback.
"I've noticed that I keep getting multiple, repeat requests for ALUMINIUM contracts in the logs."
Flippant answer: This is part of my master plan to persuade Americans that they are spelling the name of this particular metal incorrectly,
Real answer: I know thats what it looks like, but that's not what is going on here. Take this line for example:
2022-12-15 19:20:24 {'type': 'update_historical_prices', 'instrument_code': 'ALUMINIUM', 'contract_date': '20221200', 'broker': 'IB', 'clientid': 274, 'component': 'ibFuturesContractPriceData'} [Warning] futures InstrumentWithIBConfigData(instrument=EU-BASIC, ib_data=symbol='SXPP', exchange='EUREX', currency='EUR', ibMultiplier='50.0', priceMagn…