ToObservable is not firing in some cases - system.reactive

Question

RX is synchronous by default so we can confirm it
int j = 0;
Observable.Range(1, 2)
.SelectMany(i => {
return new[]{1}.ToObservable()
.Select(i1 => {
new[]{1}.ToObservable().Subscribe(i2 => j = 1);
return 0;
})
;
})
.Subscribe();
j.ShouldBe(1);
however in my code base I have a similar query that does not fire unless i use the Immediate scheduler.
public static IObservable<GitHubIssue> Save(this IObservable<IReadOnlyList<Issue>> source, IGitHubRepository repository){
var objectSpace = repository.ObjectSpace;
return source.SelectMany(list => list.ToObservable().Select(issue => {
var gitHubIssue = objectSpace.CreateObject<GitHubIssue>();
gitHubIssue.Id = issue.Id;
issue.Labels.ToObservable(Scheduler.Immediate).Select(label => {
var gitHubLabel =objectSpace.GetObjectsQuery<GitHubLabel>(true).FirstOrDefault(_ => label.Name == _.Name) ??
objectSpace.NewGitHubLabel(label);
gitHubIssue.Labels.Add(gitHubLabel);
return gitHubLabel;
}).Subscribe();
//previous selector is not executed
i fail to see the relation and why this happens

Answer 1

"RX is synchronous by default" - No, it is not. Each operator has its own default.
Take Observable.Range for example. Here's the implementation for when you don't provide a Scheduler:
public virtual IObservable<int> Range(int start, int count)
{
return Range_(start, count, SchedulerDefaults.Iteration);
}
Which in turn uses:
internal static IScheduler Iteration
{
get
{
return CurrentThreadScheduler.Instance;
}
}
If I take Observable.Timer as an counterpoint, I have this code:
public virtual IObservable<long> Timer(TimeSpan dueTime)
{
return Timer_(dueTime, SchedulerDefaults.TimeBasedOperations);
}
Which uses:
internal static IScheduler TimeBasedOperations
{
get
{
return DefaultScheduler.Instance;
}
}
The fact that you have to put in .ToObservable(Scheduler.Immediate) says you have an operator that doesn't use Scheduler.Immediate by default.
Now, ignoring all of this, what you should never ever do inside an observable pipeline is subscribe to another observable. Never ever. When you do this you are relying on side-effects and that's what's going wrong in your code.
You should always assume that any call to Subscribe runs sometime in the future, so even your assertion that j.ShouldBe(1) shouldn't ever be used after a Subscribe.
Your sample code should be more like this:
int j = 0;
Observable
.Range(1, 2)
.SelectMany(i =>
{
return
new[] { 1 }
.ToObservable()
.Select(i1 =>
{
return 1;
})
;
})
.Subscribe(x =>
{
j = x;
/* j only valid here */
});
/* j NOT valid here */
Rational concrete example of a side-effect:
int j = 0;
Observable
.Delay(Observable.Return(42), TimeSpan.FromSeconds(2.0))
.Do(x => j = x)
.Subscribe();
Console.WriteLine(j);
Ultimately j will be equal to 42, but not when Console.WriteLine(j) is called. Never rely on state outside of the observable that's updated within the observable.