Seems this is due to the split detection mechanism built into JUNOS and becuase it is only a 2 member stack.
Virtual Chassis Split
In rare cases, Virtual Chassis configurations can be “split” when a single switch, cable or Virtual Chassis port in a chained topology fails, or when two or more adjacent switch members lose connectivity in a ring topology. Prior to Junos OS 9.3, such a split would initiate a new Master re-election process in each of the new segments, resulting in two or more identical, active Virtual Chassis configurations unaware of each other’s presence. This could create problems at the network level when, for example, each of the new Virtual Chassis segments contain the same routing information, resulting in two or more “routers” in the network with identical IDs, networks, advertisements, etc.
To alleviate this problem, beginning with Junos OS 9.3, an enhancement option called Virtual Chassis “split-detection” has been added so that, following a Virtual Chassis split, no more than one segment would remain active and operational under the original configuration. All other segments created by the split are forced into an “inactive” Virtual Chassis state, with all switch members assuming a line card role with no Master or Backup. Users must either manually reload the factory default configuration on the inactive switch members or resolve the faults that caused the split (e.g. repair or replace the broken Virtual Chassis cables or member switches) before the switches can rejoin the active Virtual Chassis configuration. Beginning with Junos OS 9.3, Virtual Chassis split detection is enabled by default; for more details about Virtual Chassis split detection and split rules, please refer to the appropriate Juniper EX4200 switch product manual.
While the Virtual Chassis split detection implementation is desirable in most cases, there are rare situations that could lead to all parts of a Virtual Chassis split being rendered inactive. For example, if a split occurs and the resulting segments have an equal number of Virtual Chassis members, the original Master and Backup switches do not fall into the same split segment, and the original Backup switch is part of the failure that triggers the split, the resulting split parts would have no “active” members. A real-world example of such a situation would be a two-member Virtual Chassis configuration. If the backup switch fails for some reason, the remaining Master switch would interpret this as a Virtual Chassis split and would put itself into an “inactive” state based on the Virtual Chassis split rules, bringing the entire Virtual Chassis down. In such cases, the Virtual Chassis split-detection option would not be desirable and should be disabled with the following CLI command:
set virtual-chassis no-split-detection