In private network mode when the vc-managemnt.json is a file such as in S3
User is suppose to put 0 as CurrentReference - this is suppose to allow automatic advancement of the ref when the file is edited and new Events added (managment.go line 125).
However, we give systemRef value as prevRef (and not system now) in this case the lines 128,129,130 will give the CURRENT ref back to us and ignore a newer Event.
There are two ways to fix this.
1) the simple fix is to create dup of the functions getCommittee (and the other two) so that they allow getting the ref of the next EVENT object if it exists.
example if i give system ref 3 and we have events [{ref:1, committee:x}, {ref: 3, committee:y}, {ref: 5, committee:z}]
the current function (which is correct in the other place it is used) return the second event object, but in this special private network case it should return the third one.
this way when you add a new event to one of the lists (committee, subscription or protocol) when nodes update to the new file they will automatically switch to the new event.
Note: in this 'way' the ref is not really a timestamp it just needs to move forward.
2) the more complex is that in the case of file containing CurrentRef as 0 the sysRef should actually be proposed block time or something similar and WHEN that time surpasses a new event item then it will choose the new ref.
This allows all the time stamps to actually mean time and the committee, subscription and protocol to happen in a specific time.
This need a lot more checks because
a) i am not sure the genesis part would currently start in the right time because the code there is not clear to me
b) in this case we might need to tweak the node-manageent.json file to allow some committee grace as the non-leader nodes might not agree with the time of the block - NOT SURE ABOUT THIS.
NOTE NOTE NOTE
private network works just fine if the vc-management file is kept where CurrentRef == PageEndRef
and both are equal or bigger than any other timestamp in that file
Since each time a new committee or subscription event (RARE cases in private ? we just don't know) is added
the file is in any case modified Another option is to degenerate the function in line 125 and decide that the value cannot be 0 anyways. However that means that we won't have ability to start vcs in private mode in specific time and modify the network (add/remove node) at specific time - these are features DEV wanted to do but may actually never come to be needed.
In private network mode when the vc-managemnt.json is a file such as in S3 User is suppose to put 0 as CurrentReference - this is suppose to allow automatic advancement of the ref when the file is edited and new Events added (managment.go line 125). However, we give systemRef value as prevRef (and not system now) in this case the lines 128,129,130 will give the CURRENT ref back to us and ignore a newer Event. There are two ways to fix this.
1) the simple fix is to create dup of the functions getCommittee (and the other two) so that they allow getting the ref of the next EVENT object if it exists. example if i give system ref 3 and we have events [{ref:1, committee:x}, {ref: 3, committee:y}, {ref: 5, committee:z}] the current function (which is correct in the other place it is used) return the second event object, but in this special private network case it should return the third one. this way when you add a new event to one of the lists (committee, subscription or protocol) when nodes update to the new file they will automatically switch to the new event. Note: in this 'way' the ref is not really a timestamp it just needs to move forward.
2) the more complex is that in the case of file containing CurrentRef as 0 the sysRef should actually be proposed block time or something similar and WHEN that time surpasses a new event item then it will choose the new ref. This allows all the time stamps to actually mean time and the committee, subscription and protocol to happen in a specific time. This need a lot more checks because a) i am not sure the genesis part would currently start in the right time because the code there is not clear to me b) in this case we might need to tweak the node-manageent.json file to allow some committee grace as the non-leader nodes might not agree with the time of the block - NOT SURE ABOUT THIS.
NOTE NOTE NOTE private network works just fine if the vc-management file is kept where CurrentRef == PageEndRef and both are equal or bigger than any other timestamp in that file Since each time a new committee or subscription event (RARE cases in private ? we just don't know) is added the file is in any case modified Another option is to degenerate the function in line 125 and decide that the value cannot be 0 anyways. However that means that we won't have ability to start vcs in private mode in specific time and modify the network (add/remove node) at specific time - these are features DEV wanted to do but may actually never come to be needed.